Skip to Content.
Sympa Menu

xom-interest - [XOM-interest] XOM and jar: URIs

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Michael Whapples <software AT mdw.onl>
  • To: xom-interest AT lists.ibiblio.org
  • Subject: [XOM-interest] XOM and jar: URIs
  • Date: Wed, 7 Dec 2016 12:56:44 +0000

When building a Document in XOM one can pass the builder.build method a string for the base URI. If I pass to this method a jar: URI (eg. jar:file:///D:/mydir/mybook.zip!/mybook.xml) as the base URI I get an exception from XOM. It appears that the Verifier in XOM for verifying the URI does not handle the jar: URI scheme correctly (it complains about a double slash (//) in the path).


In Java (at least Java7 and higher) the jar: protocol is fully handled and such a URI can be used for accessing files inside a zip file.


As far as I can tell allowing such a URI to be passed in would not cause issues, the base URI could be used to resolve external resources referenced from the XML file. May be I am missing something inside XOM where this might cause an issue.


Would it be possible for this to be fixed in future versions of XOM? Alternatively is there another way for me to have the base URI reference a location in a zip file?


I tried creating a custom URL protocol handler for Java and modified the base URI to use this protocol (eg. zipfile:///D:/mydir/mybook.zip!/mybook.xml) but I could not get the JDK to pick up this protocol handler (I was setting the java.protocol.handler.pkgs system property but with no success). This option seems too complicated, particularly when the jar: protocol is supported by the JDK by default.


My only solution at the moment seems to be modify the base URI to something XOM is happy with (eg. jar-file:///D:/mydir/mybook.zip!/mybook.xml) pass this modified base URI to build. Then within a entity resolver catch the use of the jar- prefix in the base URI and change it back to jar: and manually resolve the external entity. A lot of work spread over many parts of the code, so far from satisfactory and why I would like a better solution.


Michael Whapples





Archive powered by MHonArc 2.6.24.

Top of Page