Bug 46612 - ant -diagnostics should talk about the XSLT processor
Summary: ant -diagnostics should talk about the XSLT processor
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.7.1
Hardware: PC All
: P2 enhancement (vote)
Target Milestone: 1.8.0
Assignee: Ant Notifications List
Keywords: XSLTBug
Depends on:
Reported: 2009-01-27 09:22 UTC by Daniel B.
Modified: 2009-01-29 07:00 UTC (History)
1 user (show)

XSLT transform exhibiting buggy behavior (1.43 KB, text/plain)
2009-01-27 09:25 UTC, Daniel B.

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel B. 2009-01-27 09:22:13 UTC
In whichever XSLT process is Ant's default XSLT processor when running
on JDK 1.6, the predicate on a step is ignored if the step has an axis 
of "self" and has a NodeTest that is a NameTest that is a QName.

See the attached Ant build file, XSLT transform, and XML input file.


  $ ant -version
  Apache Ant version 1.7.1 compiled on June 27 2008
  $ java -version
  java version "1.6.0_10"
  Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
  Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)

Ant installation is not customized.

(Yes, this is not directly an Ant bug, but this needs someone who
knows what Ant's default XSLT processor is report the bug upstream
or tell me enough so I can.)
Comment 1 Daniel B. 2009-01-27 09:25:41 UTC
Created attachment 23183 [details]
XSLT transform exhibiting buggy behavior
Comment 2 Daniel B. 2009-01-27 09:32:09 UTC
I can't attach the remaining two attachments (a simple Ant build file invoking
the XSLT task to run the transform, and a simple XML file for input to the
transform (containing simply "<root/>")).

Bugzilla is reporting:

   The content type text/xml is invalid. Valid types must be of the form 
   foo/bar where foo  is either application, audio, image, message, model, 
   multipart, text, or video.

when I try upload files to create additionl attachments.
Comment 3 Stefan Bodewig 2009-01-27 20:51:32 UTC
Ant uses the XSLT processor of the JDK or whatever you specify via the endorsed standards mechanism (or the task's factory configuration) - it doesn't dictate any one of them,

In any case it is a bug in the processor, not in Ant, and there is nothing we could do.
Comment 4 Daniel B. 2009-01-28 07:44:47 UTC
(In reply to comment #3)
> Ant uses the XSLT processor of the JDK or whatever you specify via the endorsed
> standards mechanism (or the task's factory configuration) - ...
> In any case it is a bug in the processor, not in Ant, 

Yes, I know.  Did you read the last paragraph of my report?

> and there is nothing we could do.

You could tell me what Ant does:

- mainly, what "the task's factory configuration" does.  (Does it do 
  nothing special and probably therefore cause use of the JDK's default 
  XSLT processor, or does it possibly so something else?), and

- whether Ant does anything different than calling the JDk's 
  normal/default API methods for transforming, and, if so, what Ant does.

And even though it's not part of Ant, since you (or someone reading this)
likely know better than I do, what is the default XSLT transformer for
JDK 1.6(.11) (so in case Sun is going to also say "it's not our bug, see
xyz", I can jump directly to xyz to report the problem)?  Is it Xalan,
or something else?  Which version?

(I'm trying to get enough information to be able to reproduce the
bug outside of Ant without spending as much time as I did beating 
against the bug in the first place.)

Hey, you changed the status to RESOLVED INVALID before the upstream bug 
in Ant's _default_ XSLT transformer for the _core_ XSLT task was fixed.  

If the bug were a non-default transformer, I'd agree, but this isn't
some optional task or a custom configuration. 

Why not track upstream bugs that affect Ant to make sure they get fixed
(e.g., the way Debian GNU/Linux tracks such bugs, tracking the bug in 
the Debian bug system (marked as reported upstream, not for the Debian 
maintainer to actually fix but just to monitor for a fix from upstream)
until the bug is fixed by the upstream maintainer?  (Wouldn't you
track in and report it upstream if the bug were in the default XML 
processor used for reading build.xml files?)

Comment 5 Stefan Bodewig 2009-01-28 08:43:52 UTC
Sorry if I sounded too harsh.

If you run "ant -diagnostics" it may help you - hmm, I just now realize it only talks about the XML parser but not the XSLT processor, reopening because of that.

The XSLT task allows you to configure the factory, that's why I talked about it.  Yes, the default is to go with whatever the system provides.

What the system provides depends on your vendor.  Sun has decided to ship a (pretty old and buggy) version of XSLTC, a variant of Apache Xalan-J that doesn't seem to become Xalan's main line anytime as their processor with Java5 and I think they still do with Java6.  I may be wrong, though.

Point 13 in http://java.sun.com/j2se/1.5.0/compatibility.html is the best hint I can give.  See also point 9 of that list.

I happen to be involved with XMLUnit as well and we've gotten lots of problem reports because of Java5's XSLT processor.  I've come to the conclusion to recommend the endorsed standards mechanism and the latest release of Xalan or Saxon to anybody doing XSLT since the default in Sun classlibs is seriously broken (and you've just hit one symptom).

I've resolved it as INVALID because it is not an Ant bug.  We (the Ant community) don't think of the JDK as our upstream and even if we did, since we don't bundle a JDK and have different release cycles this would be impossible to track.

The problem you see likely doesn't affect people using Apple's JVM on a Mac, IBM's on anything, OpenJDK 6 or Apache Harmony, for example (they will see different bugs).

IMHO there is a difference between a distribution that bundles packages and a single package that happens to depend on another package which may be provided by several different "vendors".

And no, we wouldn't track an issue in Xerces (which happens to be the default parser for most JDKs - in different versions, of course) here either.
Comment 6 Stefan Bodewig 2009-01-29 07:00:06 UTC
ant -diagnostics will now (svn revision 738872 ) emit something like

 XSLT Processor information
XSLT Processor : org.apache.xalan.transformer.TransformerIdentityImpl
XSLT Processor Location: SOME-PATH\xalan-2.7.1.jar


 XSLT Processor information
XSLT Processor : com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl
XSLT Processor Location: SOME-OTHER-PATH\jre\lib\rt.jar

the later is the default on the JDK 1.6 installation of my windows work machine.

Not sure whether it helps tracking down the problem.  In your case I really
recommend downloading Xalan-J 2.7.1 and configuring Ant to use it.

Unfortunately there is no (even remotely) portable way to determine the version.