Bug #6205
closed
xsl:try/xsl:catch doesn't catch java.net.URISyntaxException from XMLResolver
Category:
Third-party product
Fixed in Maintenance Release:
Description
Saxon 10.6 and 11.3 are dying during execution of
<xsl:try>
<xsl:apply-templates select="doc('xml-inputfile.xml')"/>
<xsl:catch><xsl:comment> ERROR during execution of xsl:apply-templates select="doc('xml-inputfile.xml')" </xsl:comment></xsl:catch>
</xsl:try>
if the doc() funtion fails with a java.net.URISyntaxException (in xmlresolver). The expected behaviour is that the <xsl:catch> code branch is executed.
(The exception itself can be avoided by setting "-Dxml.catalog.fixWindowsSystemIdentifiers=true", see #5580 )
An example is enclosed in the attched zip file.
Files
Do you have a stack trace?
As far as I can see the XdmResolver isn't supposed to be throwing an URISyntaxException, the first thing is we need to find where it's coming from.
Running the run.bat fro the attached ZIP file:
C:\_co\OVI-core-ThirdPartyPackages\_TESTS+BUGS\77_Testsuite\Testdata\Input\Bugs\Saxon\#6205_xmlresolver_try_catch>run.bat
C:\_co\OVI-core-ThirdPartyPackages\_TESTS+BUGS\77_Testsuite\Testdata\Input\Bugs\Saxon\#6205_xmlresolver_try_catch>CALL "C:\_co\OVI-core-ThirdPartyPackages\_TESTS+BUGS\06_Tools\OpenJDK.JRE.TemurinCustom_17.0.1.12\bin\java.exe" -cp "C:\_co\OVI-core-ThirdPartyPackages\_TESTS+BUGS\06_Tools\SaxonJ_11.6.0\*;C:\_co\OVI-core-ThirdPartyPackages\_TESTS+BUGS\06_Tools\SaxonJ_11.6.0\lib\*" net.sf.saxon.Transform -xsl:"C:\_co\OVI-core-ThirdPartyPackages\_TESTS+BUGS\77_Testsuite\Testdata\Input\Bugs\Saxon\#6205_xmlresolver_try_catch\\main.xsl" -dtd:off -expand:off -it:main -o:"C:\_co\OVI-core-ThirdPartyPackages\_TESTS+BUGS\77_Testsuite\Testdata\Input\Bugs\Saxon\#6205_xmlresolver_try_catch\\xml-outputfile.xml"
No license file found - running with licensable features disabled
java.lang.IllegalArgumentException: java.net.URISyntaxException: Illegal character in path at index 1: .\test.dtd
at org.xmlresolver.CatalogResolver.resolveEntity(CatalogResolver.java:292)
at org.xmlresolver.Resolver.resolveEntity(Resolver.java:199)
at net.sf.saxon.lib.CatalogResourceResolver.resolveEntity(CatalogResourceResolver.java:194)
at net.sf.saxon.lib.EntityResolverWrappingResourceResolver.resolveEntity(EntityResolverWrappingResourceResolver.java:46)
at java.xml/com.sun.org.apache.xerces.internal.util.EntityResolver2Wrapper.resolveEntity(Unknown Source)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntityAsPerStax(Unknown Source)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(Unknown Source)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(Unknown Source)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at net.sf.saxon.resource.ActiveSAXSource.deliver(ActiveSAXSource.java:190)
at net.sf.saxon.resource.ActiveStreamSource.deliver(ActiveStreamSource.java:65)
at net.sf.saxon.Configuration$1.deliver(Configuration.java:4020)
at net.sf.saxon.event.Sender.send(Sender.java:105)
at net.sf.saxon.functions.DocumentFn.makeDoc(DocumentFn.java:311)
at net.sf.saxon.functions.Doc.call(Doc.java:140)
at net.sf.saxon.expr.FunctionCall.iterate(FunctionCall.java:562)
at net.sf.saxon.expr.instruct.ApplyTemplates.apply(ApplyTemplates.java:338)
at net.sf.saxon.expr.instruct.ApplyTemplates.process(ApplyTemplates.java:294)
at net.sf.saxon.expr.TryCatch.process(TryCatch.java:341)
at net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:757)
at net.sf.saxon.expr.instruct.NamedTemplate.expand(NamedTemplate.java:266)
at net.sf.saxon.trans.XsltController.callTemplate(XsltController.java:873)
at net.sf.saxon.s9api.Xslt30Transformer.callTemplate(Xslt30Transformer.java:485)
at net.sf.saxon.Transform.processFile(Transform.java:1376)
at net.sf.saxon.Transform.doTransform(Transform.java:871)
at net.sf.saxon.Transform.main(Transform.java:81)
Caused by: java.net.URISyntaxException: Illegal character in path at index 1: .\test.dtd
at java.base/java.net.URI$Parser.fail(Unknown Source)
at java.base/java.net.URI$Parser.checkChars(Unknown Source)
at java.base/java.net.URI$Parser.parseHierarchical(Unknown Source)
at java.base/java.net.URI$Parser.parse(Unknown Source)
at java.base/java.net.URI.<init>(Unknown Source)
at org.xmlresolver.CatalogResolver.resolveEntity(CatalogResolver.java:268)
... 33 more
Fatal error during transformation: java.lang.IllegalArgumentException: java.net.URISyntaxException: Illegal character in path at index 1: .\test.dtd
Sorry for the delay.
Current versions of the XmlResolver do not throw a URISyntaxException here, they throw an IllegalArgumentException, which Saxon is catching and turning into a regular XPathException that try/catch will resolve.
It seems this was fixed by https://github.com/xmlresolver/xmlresolver/issues/72
I would think the solution is to make the next maintenance releases of 10.x (if any) and 11.x use an up-to-date version of the XmlResolver.
- Category set to Third-party product
- Status changed from New to In Progress
- Assignee set to Norm Tovey-Walsh
- Priority changed from Low to Normal
- Status changed from In Progress to Duplicate
This looks like the same bug as #6222
If the input document contains a "\" in a system identifier and the identifier isn't resolved by the catalog, Saxon will attempt to resolve the original (invalid) URI and that will fail.
This work item is about »xsl:try/xsl:catch doesn't catch …«. #6222 is one reason for a java.net.URISyntaxException, but it is not a duplicate of this ticket.
I think it's a duplicate in the sense that the symptoms might be different, but the internal problem is the same and the same code change will fix both.
Please register to edit this issue
Also available in: Atom
PDF
.