ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 36653] xslt task: new attribute xinclude
Date Sat, 13 Dec 2008 20:57:55 GMT

--- Comment #9 from Trevor Harmon <>  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
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=""

This is where problems start. Adding the above factory attribute causes

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 is making this call:

  parser.setFeature("", true);

But when this call propagates to Xerces, its looks in
its list of recognized feature strings, doesn't find
"", and throws

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
"". It only knows about
"". (Not sure why.)

Saxon attempts to handle this gracefully, as shown in this snippet from its

  boolean tryAgain = false;
  try {
      // This feature name is supported in the version of Xerces bundled with
JDK 1.5
      parser.setFeature("", 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("", 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

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
"" and
"" are there, but
"" is not.

So the root of this problem is that Xerces is not adding
"" to its feature list. I even tried to
add it explicitly in Ant's TraXLiaison.getSource methods:

  spFactory.setFeature("", 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

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

View raw message