Bug 41314 - Xslt task's <factory> nested element always causes ClassNotFoundException
Summary: Xslt task's <factory> nested element always causes ClassNotFoundException
Status: RESOLVED DUPLICATE of bug 46172
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.7.0
Hardware: All All
: P2 major with 2 votes (vote)
Target Milestone: 1.8.0
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-06 21:35 UTC by Trevor Harmon
Modified: 2008-11-24 08:13 UTC (History)
2 users (show)



Attachments
Test case demonstrating ClassNotFoundException when using <factory> nested element (1.26 KB, application/zip)
2007-01-06 21:38 UTC, Trevor Harmon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Trevor Harmon 2007-01-06 21:35:15 UTC
CONTEXT

For the Xslt task, it is sometimes necessary to specify an alternate processor, such as Saxon. The usual 
way to do this is via the classpath attribute of the Xslt task. Simply adding the Saxon JAR to this attribute 
allows Ant to find, load, and use the Saxon processor.

PROBLEM

If a Xalan processor happens to be listed in the CLASSPATH environment variable, this technique does 
not work. Xalan, not Saxon, is used instead. It appears that CLASSPATH trumps Xslt's classpath attribute. 
(Note that those who've installed Ant via the Fink package manager have Xalan in their CLASSPATH by 
default, so this is not an uncommon situation.)

WORKAROUNDS

There are three workarounds for this problem:

1) Alter the CLASSPATH variable so that the Saxon JAR is listed before Xalan
2) Add the parameter "-lib <path-to-Saxon-JAR>" when calling Ant on the command line
3) Use the <factory> sub-element of the Xslt task to specify the Saxon factory class explicitly, thus 
overriding Xalan.

The first two workarounds are unsatisfactory because they impose an artificial requirement on users to 
adjust their Ant startup classpath. As for the third workaround, it does not work at all; it always results 
in a ClassNotFoundException.

TEST CASE

The attached test case reproduces the ClassNotFoundException of workaround #3. It has been verified 
on the 2007-01-06 nightly build. To reproduce:

1) Download the test case and extract the archive to a directory of your choice
2) Make sure your system's CLASSPATH environment variable is empty
3) Switch to that directory and run "ant". The Saxon processor will be used in the transformation, as 
indicated by the warning "Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor". This is the 
expected behavior because the Saxon JAR is specified in the Xslt task's classpath attribute.
4) Add the provided Xalan JAR to your system's CLASSPATH environment variable. (e.g., "export 
CLASSPATH=xalan-2.7.0.jar")
5) Run "ant" again. The Xalan processor is used, which is not the desired behavior.
6) Attempt to workaround this problem by uncommenting the <factory> nested element in build.xml 
(line 12).
7) Run "ant" again. You will see an error: "java.lang.ClassNotFoundException: 
net.sf.saxon.TransformerFactoryImpl".

This is not the expected behavior because the class is contained in the provided Saxon JAR, and this JAR 
is listed in Xslt's classpath attribute.

REFERENCES

This issue is discussed in the Ant FAQ:

http://ant.apache.org/faq.html#delegating-classloader

However, the workaround given in the FAQ requires the user to alter the Ant installation. This is a 
burden for users and should not be necessary. In fact, it has been eliminated in Ant 1.7.0, but only for 
the <junit> task, as described in bug #38799. The Xslt task still needs to be fixed.
Comment 1 Trevor Harmon 2007-01-06 21:38:31 UTC
Created attachment 19372 [details]
Test case demonstrating ClassNotFoundException when using <factory> nested element

Extra JARs for Saxon and Xalan are required to run this test case. They can be
obtained here:

http://vocaro.com/trevor/files/saxon-b-8.8.jar
http://vocaro.com/trevor/files/xalan-2.7.0.jar
Comment 2 Trevor Harmon 2007-01-08 00:46:05 UTC
I've discovered a fourth workaround, as discussed on my blog:

http://www.vocaro.com/trevor/blog/2007/01/08/how-to-use-saxon-with-ant/

However, it's a bit of a hack, and workaround #3 is still the ideal solution...if it would work.
Comment 3 David Corley 2008-03-25 04:41:37 UTC
I've increased the severity of this issue, as it can really only be described as broken functionality. If the user specifies both a classpath and factory within an <xslt> task, then Ant should look for the factory on the specified classpath, period.
Comment 4 Dave Pawson 2008-04-13 00:57:08 UTC
Is there any chance of this bug being fixed please?
It's affecting both xslt 1.0 and 2.0 processors?
Comment 5 Stefan Bodewig 2008-11-24 08:13:23 UTC
I know this bug is older, but bug 46172 points to the root cause.

*** This bug has been marked as a duplicate of bug 46172 ***