[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Choosing the XSL Enginer with JDK1.4
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 ....
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
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|