Re: [xsl] Choosing the XSL Enginer with JDK1.4

Subject: Re: [xsl] Choosing the XSL Enginer with JDK1.4
From: Nigel Whitaker <nigelw@xxxxxxxxxxxxxxx>
Date: Tue, 29 Jul 2003 16:46:33 +0100
Hello Hari,

On Monday, July 21, 2003, at 04:06 pm, Harihara Vinayakaram wrote:

I tried putting the -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar


The bootclasspath stuff and setting the java.endorsed.dirs system property are
useful for selecting between different implementations/versions of the same class,
for example, for Xalan this is "org.apache.xalan.processor.TransformerFactoryImpl"


In JAXP there is a stage before this, where the implementation class is chosen,
see the javadoc for the newInstance() methods of the ParserFactory and TransformerFactory:


http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/parsers/ SAXParserFactory.html#newInstance()
http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/transform/ TransformerFactory.html#newInstance()


Even if you are not creating a parser yourself (and using SAXSource input to the
XSLT processor), it is likely that the XSLT processor, when using StreamSource
input or when invoked as a command line processor, is using the JAXP factory methods
to instantiate an XML parser.


What's important in the javadoc is the ordered list of 4 ways in which the factory
locates the implementation class. In some cases introducing
a jar file onto the classpath will cause a higher priority
method to be used in the lookup procedure.


For example, adding Saxon's (6.5.2) saxon.jar to the classpath introduces
a 'level-3' lookup method using META-INF entries in the jar manifest,
which overrides the level-4 default typically built into J2SEs 1.4.0/1.4.1 from
Sun. Alot of people (semi-mistakenly) think they are getting Saxon as a consequence of
adding it to the classpath, and think in purely classpath terms, and then wonder why adding,
say a recent version of Xalan to the classpath, does not override the built-in, broken
versions included in JDK 1.4.[01]...


Your message is a little confusing about exactly what you are trying to do, you
seem to be interchanging the words 'parser', 'engine' and 'processor'
which I find confusing, but based on:


> Irrespective of what I try to do the Oracle's Parser is getting invoked.

I guess you are trying to use the Xerces XML parser? If this
is the case I'd suggest using a system property (the 'level-1' method in the factory
location list) to specify Xerces as the parser. You can do this either
on the command line or in java code, for example:


java - Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFact oryImpl -cp ....


System.setProperty("javax.xml.parsers.SAXParserFactory", "org.apache.xerces.jaxp.SAXParserFactoryImpl");

This should then override whatever techniques are used in the JDK and/or any jar files
added to the classpath for selecting the parser. This of course assumes that your
XSLT processor is well behaved and is using the JAXP factory methods internally.
If it is not then you may have to write some java code to instantiate
the parser yourself and then supply SAXSource inputs to the XSLT processor.


I hope this helps, its based on experience with Saxon and Xalan-J over several JDK
revisions; I have very little experience of the Oracle software, but unless its
implementation is crippled in some strange way, the above stuff should apply.


Nigel


-- Nigel Whitaker, DeltaXML: "Change control for XML, in XML", www.deltaxml.com / nigel.whitaker@xxxxxxxxxxxx


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list



Current Thread