Java 1.5 has JAXP classes just like Java 1.4, however, JUnitReport cannot run because it cannot find Xalan. The message I get is: BUILD FAILED file:f:/d-haven.org/dojo/build.xml:62: Could not find xalan2 nor xalan1 in the classpath. Check http://xml.apache.org/xalan-j I will upgrade 1.6.1, but this seems to be an ugly issue. If the problem persists, I will update this bug.
Still a problem in Version 1.6.1
If I explicitly add the Xalan Jars to the ANT/lib directory, then it works. Any reason you can't just use whatever is in the JDK?
I spoke too soon: Here is the stack trace from JunitReport: [junitreport] Using Xalan version: Xalan Java 2.6.0 BUILD FAILED java.lang.ExceptionInInitializerError at org.apache.tools.ant.Project.executeTarget(Project.java:1224) at org.apache.tools.ant.Project.executeTargets(Project.java:1063) at org.apache.tools.ant.Main.runBuild(Main.java:632) at org.apache.tools.ant.Main.startAnt(Main.java:183) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:197) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:56) Caused by: java.lang.ExceptionInInitializerError at org.apache.xml.serializer.ToStream.<init>(ToStream.java:112) at org.apache.xml.serializer.ToHTMLStream.<init>(ToHTMLStream.java:557) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct orAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC onstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:415) at java.lang.Class.newInstance0(Class.java:322) at java.lang.Class.newInstance(Class.java:275) at org.apache.xml.serializer.SerializerFactory.getSerializer(SerializerF actory.java:91) at org.apache.xalan.transformer.TransformerImpl.createSerializationHandl er(TransformerImpl.java:1097) at org.apache.xalan.transformer.TransformerImpl.createSerializationHandl er(TransformerImpl.java:981) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImp l.java:1187) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImp l.java:1170) at org.apache.tools.ant.taskdefs.optional.junit.Xalan2Executor.execute(X alan2Executor.java:45) at org.apache.tools.ant.taskdefs.optional.junit.AggregateTransformer.tra nsform(AggregateTransformer.java:147) at org.apache.tools.ant.taskdefs.optional.junit.XMLResultAggregator.exec ute(XMLResultAggregator.java:136) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:269) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:301) at org.apache.tools.ant.Target.performTasks(Target.java:328) at org.apache.tools.ant.Project.executeTarget(Project.java:1215) ... 5 more Caused by: java.lang.NumberFormatException: For input string: "be found at http: //www.iana.org/assignments/character-sets" at java.lang.NumberFormatException.forInputString(NumberFormatException. java:48) at java.lang.Integer.parseInt(Integer.java:446) at java.lang.Integer.valueOf(Integer.java:525) at java.lang.Integer.decode(Integer.java:903) at org.apache.xml.serializer.Encodings.loadEncodingInfo(Encodings.java:3 93) at org.apache.xml.serializer.Encodings.<clinit>(Encodings.java:429) ... 26 more --- Nested Exception --- java.lang.ExceptionInInitializerError at org.apache.xml.serializer.ToStream.<init>(ToStream.java:112) at org.apache.xml.serializer.ToHTMLStream.<init>(ToHTMLStream.java:557) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct orAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC onstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:415) at java.lang.Class.newInstance0(Class.java:322) at java.lang.Class.newInstance(Class.java:275) at org.apache.xml.serializer.SerializerFactory.getSerializer(SerializerF actory.java:91) at org.apache.xalan.transformer.TransformerImpl.createSerializationHandl er(TransformerImpl.java:1097) at org.apache.xalan.transformer.TransformerImpl.createSerializationHandl er(TransformerImpl.java:981) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImp l.java:1187) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImp l.java:1170) at org.apache.tools.ant.taskdefs.optional.junit.Xalan2Executor.execute(X alan2Executor.java:45) at org.apache.tools.ant.taskdefs.optional.junit.AggregateTransformer.tra nsform(AggregateTransformer.java:147) at org.apache.tools.ant.taskdefs.optional.junit.XMLResultAggregator.exec ute(XMLResultAggregator.java:136) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:269) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:301) at org.apache.tools.ant.Target.performTasks(Target.java:328) at org.apache.tools.ant.Project.executeTarget(Project.java:1215) at org.apache.tools.ant.Project.executeTargets(Project.java:1063) at org.apache.tools.ant.Main.runBuild(Main.java:632) at org.apache.tools.ant.Main.startAnt(Main.java:183) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:197) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:56) Caused by: java.lang.NumberFormatException: For input string: "be found at http: //www.iana.org/assignments/character-sets" at java.lang.NumberFormatException.forInputString(NumberFormatException. java:48) at java.lang.Integer.parseInt(Integer.java:446) at java.lang.Integer.valueOf(Integer.java:525) at java.lang.Integer.decode(Integer.java:903) at org.apache.xml.serializer.Encodings.loadEncodingInfo(Encodings.java:3 93) at org.apache.xml.serializer.Encodings.<clinit>(Encodings.java:429) ... 26 more
As to why it doesn't work without explicit Xalan jars, Sun has repackaged Xalan, partly into com/sun/org/apache/xalan, but that doesn't look complete either. Ant is using reflection to find org.apache.xalan.processor.XSLProcessorVersion and that fails. I can't comment on the second part (NumberFormatException) but vaguely recall that I've seen something like this in a different bvug report before - sorry, no more details.
I've just retried to work on this with JDK 1.5 beta2, I've patched the build file and <junitreport> to accept JDK 1.5 as executor - and will commit the changes to CVS HEAD shortly - but it still doesn't work. The stylesheet we use for junitreport uses Xalan redirect extensions and I fail to locate them in JDK1.5, so running <junitreport> fails with > Errors while applying transformations: java.lang.RuntimeException: Unrecognized > XSLTC extension 'org.apache.xalan.lib.Redirect:write' It requires is way more than my working XSLT knowledge to come up with a fix here, I'm afraid.
http://java.sun.com/j2se/1.5.0/compatibility.html#4959783 seems to be the relevant piece. In short, JDK 1.5 does not ship with Xalan, as far as Ant is concerned. We'll probably need an XSLTC implementation of our junitreport stylesheets.
Well, I had a quick look at the XSL 2.0 spec, and they do have a <xsl:result- document> element which allows outputting to several documents, so no need to rely on extensions theoretically. (Where I'm confused is how XSL 2.0 relates to XSL 1.1 which also has output to mutliple documents. No mention I could see in the spec!). Does XSLTC support <xsl:result-document> already? So theoretically (again), we could apply a small transformation to the stylesheet itself to make it XSL 2.0 compatible, although rewritting the stylesheet for XSL 2.0 is another options. I worry about maintenance if we duplicate it though. JDK 1.5 is such a big leap (of faith?)... One wonders if it hasn't too many new things. --DD
Xalan is a XSLT 1.0 implementation and does not support XSLT 2.0 xsl:result- document (Saxon 7.x does). About XSLTC, I did a quick hack and I'm having a look but...it looks like I need to upgrade to 2GB of memory before getting some results from it. The memory usage is absolutely massive. Running w/ JDK 1.5B1 (xalan 2.5.2) it jumps straight to 420MB and and I'm transforming a 32.3KB xml...I'm running out of memory (only have a 512MB laptop) about 60s later while it takes less than a second to perform the transformation with JDK 1.4 and endorsed Xalan 2.6.0 (w and w/o xsltc) Running 1.5B1 with Xalan 2.6.0 gives the exception mentionned above (which was mentionned in PR 28920 for the Xalan project but closed w/o investigations) As for the stylesheet, it is a matter of changing the namespace declaration (but it should probably fail now with xalan 1 - no more used in a sane world though - ) to xmlns:redirect="http://xalan.apache.org/xalan/redirect" Nothing committed yet of course.
Ok I found what is the root cause of the exception in Xalan. That's a bug in JDK 1.5B1 for java.util.Properties as they completely rewrote it and a comment is only considered if it is a newline, in our case, the comment ends up as a property. I could not check for B2 but it does work fine for JDK 1.4 of course. For a quick'n dirty fix for JDK 1.5: In xalan.jar extract the file org/apache/xml/serializer/Encoding.properties You will notice that the last line is # can be found at http://www.iana.org/assignments/character-sets Add an extra line feed at the end of this line. Run your JVM 1.5 with system property: -Dorg.apache.xalan.serialize.encodings=file://my/path/to/Encodings.properties
I've just checked with the Xalan/Xerces combo from CVS HEAD that Gump places on my disk and it seems to work for either 1.5B1 and 1.5B2 on Linux. I'm glad you are chiming in Stephane. My first approach was to really simply change the namespace URI but I was afraid of breaking Xalan1. Maybe we should duplicate the styles and use different defaults for Xalan1? Do you know whether all Xalan-J 2 versions support http://xalan.apache.org/xalan/redirect instead of the Java class name?
Just downloaded JDK1.5B2 and the java.util.Properties bug is fixed. My current fix is a bit more complicated as I'm looking in order of preference for: - (Xalan 2 XSLTC) org.apache.xalan.xsltc.ProcessorVersion - (XSLTC JDK 1.5) com.sun.org.apache.xalan.internal.xsltc.ProcessorVersion - (Xalan 2) org.apache.xalan.processor.XSLProcessorVersion - (Xalan 1) org.apache.xalan.xslt.XSLProcessorVersion This is a bit brain dead for now as the version information could not be related at all to the default|selected transformer but it normally means you do have a transformer available so I will have to look for something a bit more solid for identification now that we have a half dozen of xalan transformer factories flying around... As for the namespace I have no idea, sorry. Do you think we should still keep backward compatibility for Xalan 1 ? As you saw last time, it was already difficult to get our hands on Xalan1 archive and Myriam had to dig into archived CDs to send us a version. Considering that JAXP is now very widespread, it would be acceptable...but of course it is always possible to duplicate and do some magic stylesheet pickup depending on the processor.
I'm not sure whether we might want to place Xalan2 in front of XSLTC given your experience with it. Otherwise I'm fine with the approach. As for Xalan-1 support. I vaguely recall that it doesn't really work today either, but if we could at least keep the current functionality I'd prefer that. No strong feelings, though.
Fixed in CVS HEAD and the 1.6 branch. Berin, if you have any chance to build Ant from source and run it against your test with JDK 1.5, that would be great.
I am opening this again, as gump on java1.5 shows it is still not working. see: http://brutus.apache.org/gump/jdk15/smartfrog/smartfrog-tasks-test/gump_work/build_smartfrog_smartfrog-tasks-test.html for an example, We are getting the fault "javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found" from our macro: <macrodef name="sf-test-report"> <attribute name="data"/> <attribute name="reports"/> <attribute name="failed"/> <sequential> <junitreport todir="@{data}"> <fileset dir="@{data}"> <include name="TEST-*.xml"/> </fileset> <report format="frames" todir="@{reports}"/> </junitreport> <fail if="@{failed}">Unit tests failed see @{reports}</fail> </sequential> </macrodef> Now, the tests are failing, which may complicate the process, but I dont expect to see exception errors. We should be able to unit test this BTW, just create a sample output.xml file and junit over it to make sure all is well.
Steve, as I already said on the list, the problem is the Gump setup in your case. You include Apache's xml-apis.jar which is configured to use Xalan as its default TransformerFactory. Since you don't include xalan as well, the task fails. You should either remove xml-apis (by saying ids="parser" in the <depend> element for Xerces) or add Xalan.
OK, closing it again, I'm very sure the problem doesn't exist, at least not in its original form, anymore. It's the second bullet in <http://stefanbodewig.blogger.de/stories/167334/#XSLTC>
(In reply to comment #16) > It's the second bullet in <http://stefanbodewig.blogger.de/stories/167334/#XSLTC> moved to <http://stefan.samaflost.de/blog/2004/10/29#XSLTC>