[Zorba-coders] [Bug 992304] Re: Executing lib_only query invokes URI resolution process
** Changed in: zorba
Milestone: None => 2.5
--
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
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp
[Zorba-coders] [Bug 992304] Re: Executing lib_only query invokes URI resolution process
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
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp
[Zorba-coders] [Bug 992304] Re: Executing lib_only query invokes URI resolution process
** Summary changed:
- module declaration invokes URI resolution process
+ Executing lib_only query invokes URI resolution process
--
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
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp
