zorba-coders team mailing list archive

[Chris Hillery <992304@xxxxxxxxxxxxxxxxxx>]

I have figured out that this only happens when compiling the query as a
library module, as with the -l command-line option. This happens because
Zorba actually creates a separate query that imports the module
namespace and executes that, registering a custom URLResolver for that
namespace URI that returns the original query.

The reason this ends up hitting the web is because the full URI mapping
is also done. So, in this case, the URL "http://www.zorba-
xquery.com/foo" gets turned into a number of candidate URIs, one of
which is "http://www.zorba-xquery.com/foo.xq";. The custom URLResolver
recognizes only the original unchanged URI, so it returns nothing for
this URI, letting Zorba fall through to the built-in URLResolvers
including the HTTPURLResolver.

The fix is easy enough - simplify the custom URLResolver so it doesn't
even check the URL it is passed. We know it will always be the URL we
are expecting, even if it's been modified by URI Mapping, so we can just
return the query file resource directly. Tested locally and this works.

** Changed in: zorba
     Assignee: (unassigned) => Chris Hillery (ceejatec)

** Branch linked: lp:~zorba-coders/zorba/bug-992304-compile-only

-- 
You received this bug notification because you are a member of Zorba
Coders, which is the registrant for Zorba.
https://bugs.launchpad.net/bugs/992304

Title:
  Executing lib_only query invokes URI resolution process

Status in Zorba - The XQuery Processor:
  New

Bug description:
  The following query:

  module namespace foo = "http://www.zorba-xquery.com/foo";;

  declare function foo:test() {
    if (fn:true())
    then 1
    else $a
  };

  (which is in the Zorba source as bin/test/mymod.xq) actually contacts
  www.zorba-xquery.com via HTTP and attempts to download /foo.xq. This
  means that the module namespace URI is undergoing URI resolution. I
  cannot imagine why this would be the case, but it leads not only to
  slowness but can cause the query to change behaviour depending on what
  www.zorba-xquery.com chooses to return. (In the original test case,
  the URL was at 28msec.com, and when 28msec.com changed from raising a
  404 error to returning a 200 with an error HTML page, the query
  started failing with a compilation error. Apparently Zorba was
  attempting to actually compile the HTML as an XQuery.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/zorba/+bug/992304/+subscriptions