On 31 Dec 2008, at 13:44, Simon Pepping wrote:
Hi Simon, Phil,
This can be achieved by manipulating your classpath. If you ensure
that saxon's jar file is before xalan in the classpath, the correct
definition as quoted below is ensured automatically. This is achieved
because the jar file has this setting in its META-INF/services
directory.
Correct, but ... this is only true in case the Java runtime does not
come bootstrapped with its own XSLT processor. Sun and IBM both bundle
Xalan, which becomes the preferred implementation unless you either
override it using the JAXP system property. GNU Classpath is an
example of a Java runtime that does not bundle its own XSLT processor.
Another option to force Saxon to be the chosen XSLT implementation at
runtime, is to specify the 'bootclasspath' system property, and make
sure Saxon's JAR ends up before the 'native' Xalan version.
Same for the parser. Fiddling with the normal classpath alone is not
sufficient to ensure that another version than the bundled one is used
at runtime.
To sum it up, the options are:
1° set the related system properties via the command-line
2° set them in a jaxp.properties file (should be located in $JRE_HOME$/
lib)
3° force the bootclasspath via the command-line, so that the desired
implementations appear before their 'native' counterparts
4° override the implementations by dropping the related JARs in
$JRE_HOME$/lib/endorsed
Both option 1° and 3° affect only one particular run of one application.
Option 2° and 4° will affect all Java-XML applications running on the
system.
Cheers, and all the best for 2009!
Andreas
