| Summary: | ant -diagnostics should talk about the XSLT processor | ||
|---|---|---|---|
| Product: | Ant | Reporter: | Daniel B. <DanielBarclay.oss> |
| Component: | Core tasks | Assignee: | Ant Notifications List <notifications> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | notifications |
| Priority: | P2 | Keywords: | XSLTBug |
| Version: | 1.7.1 | ||
| Target Milestone: | 1.8.0 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Attachments: | XSLT transform exhibiting buggy behavior | ||
|
Description
Daniel B.
2009-01-27 09:22:13 UTC
Created attachment 23183 [details]
XSLT transform exhibiting buggy behavior
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. 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. (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?) 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. 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 or ------------------------------------------- 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. |