Project

Profile

Help

Bug #1853

closed

"jar" URIs no longer supported in 9.5

Added by Romain Deltour almost 11 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
JAXP Java API
Sprint/Milestone:
-
Start date:
2013-07-23
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

Description

Trying to import a stylesheet packaged in a Jar file from another stylesheet in the same jar raises an exception in Saxon 9.5.x. It worked in Saxon 9.4.x. The change of behavior doesn't seem to be documented in the release notes.

Attached is a jar to reproduce the error, along with a ZIP containing the sources of the jar.

With Saxon 9.5:

$ java -cp Saxon-HE-9.5.0.1.jar:xslt-0.0.1-SNAPSHOT.jar org.example.Main
Warning: on line 8 of main.xsl:
  Evaluation will always throw a dynamic error: Base URI {jar:file:/Users/Romain/Work/ec...}
  is a non-hierarchic URI
Error on line 8 of main.xsl:
  FORG0002: Base URI {jar:file:/Users/Romain/Work/ec...} is a non-hierarchic URI
net.sf.saxon.s9api.SaxonApiException: Base URI {jar:file:/Users/Romain/Work/ec...} is a non-hierarchic URI
	at net.sf.saxon.s9api.XsltTransformer.transform(XsltTransformer.java:454)
	at org.example.Main.main(Main.java:23)
Caused by: net.sf.saxon.trans.XPathException: Base URI {jar:file:/Users/Romain/Work/ec...} is a non-hierarchic URI

With Saxon 9.4:

$ java -cp Saxon-HE-9.4.0-9.jar:xslt-0.0.1-SNAPSHOT.jar org.example.Main
<?xml version="1.0" encoding="UTF-8"?><uri>jar:file:/Users/Romain/Work/eclipse/workspaces/maven-plugin/xslt/target/xslt-0.0.1-SNAPSHOT.jar!/xslt/imported.xsl</uri>

This can be worked around by setting a System ID to the source with a custom URI and associating a URIResolver that parse this URI and loads the resource from the Jar.


Files

xslt-0.0.1-SNAPSHOT.jar (3.24 KB) xslt-0.0.1-SNAPSHOT.jar Romain Deltour, 2013-07-23 02:47
saxon-jar-uri.zip (3.3 KB) saxon-jar-uri.zip Romain Deltour, 2013-07-23 02:47
Actions #1

Updated by Michael Kay almost 11 years ago

  • Category set to JAXP Java API
  • Status changed from New to In Progress
  • Assignee set to Michael Kay
  • Priority changed from Low to Normal

Thanks for reporting it. We'll look into it. I can confirm this wasn't an intended change. JAR file URI support has to be handled specially because these "URIs" are not actually legal RFC2396 URIs and are rejected by the java.net.URI class. The change probably results from a tightening up in the implementation of resolve-uri() to be stricter about conforming to the RFC rules.

Actions #2

Updated by Michael Kay almost 11 years ago

This is tricky. The spec for resolve-uri() has become tighter, and the Saxon implementation has become stricter in order to ensure it passes all the conformance tests. The XPath 2.0 spec said you should use an algorithm "such as those described in [RFC 2396] or [RFC 3986]", but the 3.0 specification provides no such license. The 3.0 spec does allow implementations optionally to support a chosen subset of LEIRIs (legacy URIs) but I'm not sure the JAR URI scheme fits into that category.

Supporting the JAR scheme in relative URI resolution for xsl:include and xsl:import is less of a conformance issue, but resolve-uri() seems to offer little wriggle-room, at least in 3.0.

Actions #3

Updated by Michael Kay almost 11 years ago

  • Status changed from In Progress to Resolved

OK, I decided to patch resolve-uri() to reinstate support for JAR URLs, even though it's non-conformant. Sometimes usability wins over conformance. Raising a patch on the 9.5 and 9.6 branches.

Actions #4

Updated by Romain Deltour almost 11 years ago

Michael Kay wrote:

I decided to patch resolve-uri() to reinstate support for JAR URLs, even though it's non-conformant. Sometimes usability wins over conformance.

It sounds reasonable to me, especially if it is well documented (as I'm sure it will be, given Saxon's quality doc). Thanks for the quick resolution.

Actions #5

Updated by O'Neil Delpratt over 10 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to 9.5.1.2

Bug fix applied in the Saxon maintenance release 9.5.1.2

Please register to edit this issue

Also available in: Atom PDF