https://issues.apache.org/bugzilla/show_bug.cgi?id=36653
--- Comment #9 from Trevor Harmon <[email protected]> 2008-12-13 12:57:54 PST --- Actually, I think the problem is more serious than that. Xinclude still doesn't work even if you work around the issue in comment #8 by setting the system property ahead of time. Using the current Ant trunk, I started out by setting ANT_OPTS="-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XIncludeParserConfiguration". This has the desired effect of changing Xerces to use XIncludeParserConfiguration instead of the default XIncludeAwareParserConfiguration. I've confirmed this through debugging. XIncludeParserConfiguration is definitely being instantiated with this setting. Next, since I'm using Saxon 9.1, I added this nested element to my <xslt> task: <factory name="net.sf.saxon.TransformerFactoryImpl"> <attribute name="http://saxon.sf.net/feature/xinclude-aware"; value="true"/> </factory> This is where problems start. Adding the above factory attribute causes org.apache.xerces.xni.parser.XMLConfigurationException. I've done some debugging to find out why this is being thrown, and I can see that Saxon is definitely trying to configure the parser for Xinclude. The sendSAXSource method in its Sender.java is making this call: parser.setFeature("http://apache.org/xml/features/xinclude-aware";, true); But when this call propagates to Xerces, its ParserConfiguration.java looks in its list of recognized feature strings, doesn't find "http://apache.org/xml/features/xinclude-aware";, and throws XMLConfigurationException. Actually, this is to be expected because the current Ant trunk is bundled with the Xerces 2.9.0 parser, and that version doesn't know about "http://apache.org/xml/features/xinclude-aware";. It only knows about "http://apache.org/xml/features/xinclude";. (Not sure why.) Saxon attempts to handle this gracefully, as shown in this snippet from its Sender.java: boolean tryAgain = false; try { // This feature name is supported in the version of Xerces bundled with JDK 1.5 parser.setFeature("http://apache.org/xml/features/xinclude-aware";, true); } catch (SAXNotRecognizedException err) { tryAgain = true; } catch (SAXNotSupportedException err) { tryAgain = true; } if (tryAgain) { try { // This feature name is supported in Xerces 2.9.0 parser.setFeature("http://apache.org/xml/features/xinclude";, true); } catch (SAXNotRecognizedException err) { ... } catch (SAXNotSupportedException err) { ... } } Unfortunately, this failover technique does not work, apparently due to a Xerces problem. When Xerces encounters the unrecognized feature string in its ParserConfigurationSettings.checkFeature method, it throws its own proprietary org.apache.xerces.xni.parser.XMLConfigurationException. I don't know why it doesn't use the standard org.xml.sax.SAXNotRecognizedException or org.xml.sax.SAXNotSupportedException. It is either a bug in Saxon (because it catches the wrong exception) or a bug in Xerces (because it throws the wrong exception). In this case, though, it doesn't actually matter because even if Saxon specified "xinclude" instead of "xinclude-aware", it still wouldn't work. That's because the feature list variable in Xerces doesn't contain either one! When ParserConfigurationSettings.checkFeature is called, I see that "http://apache.org/xml/features/xinclude/fixup-base-uris"; and "http://apache.org/xml/features/xinclude/fixup-language"; are there, but "http://apache.org/xml/features/xinclude"; is not. So the root of this problem is that Xerces is not adding "http://apache.org/xml/features/xinclude"; to its feature list. I even tried to add it explicitly in Ant's TraXLiaison.getSource methods: spFactory.setFeature("http://apache.org/xml/features/xinclude";, true); or: spFactory.setXIncludeAware(true); But they simply cause javax.xml.parsers.ParserConfigurationException to be thrown in org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser. So now I'm basically stuck, but I hope that the analysis above might help someone. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
