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

Reply via email to