Saxon

Legacy ID: #4222144 Legacy Poster: Michael Kay (mhkay)

The stack trace isn't consistent with the information you supplied. The trace shows that the source object being supplied is a SAXSource, whereas your code shows a DOMSource being supplied. Also, the calling code is com.ibm.wps.state.logging.Helper.dump, which is presumably not your code. This suggests that the IBM code is calling Saxon with a SAXSource and the XMLReader in the SAXSource is initialized to an XMLReader that (contrary to the SAX specification) doesn't allow the namespaces property to be set to true. I think there has been a similar problem in the past that was fixed by moving to a later version of Xerces. The problem is that the IBM code is using JAXP interfaces to get its identity transformer, and it's not expecting that it will pick up the Saxon implementation. The Saxon implementation is stricter about requiring the XMLReader to conform to the SAX specification than the implementation that the IBM code expected to find. You may be able to solve the problem by setting the JAXP system properties so that the Xalan transformer factory is used by default; when you want to use the Saxon transformer factory you will then have to load it explicitly.

Legacy ID: #4222322 Legacy Poster: Alexander Pogrebinsky (avpog)

Thank you for so fast reply. Now I see clearly that problem is in IBM not our custom code. It is a good idea to set Saxon as transformer factory dynamically but how can I "load it explicitly"? I know 4 ways to set transformer factory: 1) System.setProperty( "javax.xml.transform.TransformerFactory", "classname") 2) The value specified at the command line using the -Djavax.xml.transform.TransformerFactory=classname option to the java interpreter 3) The class named in the lib/jaxp.properties properties file in the JRE directory, in a line like this one: javax.xml.transform.TransformerFactory=classname 4) The class named in the META-INF/services/javax.xml.transform.TransformerFactory file in the JAR archives available to the runtime The first 3 of them extractly has global JVM effect. Is the last relative to war module if JAR archive is palced in war's lib subdirectory? Or you means another way to "load it explicitly"?

Legacy ID: #4222373 Legacy Poster: Michael Kay (mhkay)

There is another way to create a TransformerFactory which is often overlooked: TransformerFactory factory = new net.sf.saxon.TransformerFactoryImpl(); This has the disadvantage that your code has a compile-time link to Saxon, but it has the advantages that (a) it is much faster than the JAXP mechanisms, and (b) you are 100% sure of which product you are loading. If you want to avoid the compile-time dependency, there is yet another way, namely Class.forName("net.sf.saxon.TransformerFactoryImpl").newInstance(). Michael Kay

Legacy ID: #4222432 Legacy Poster: Alexander Pogrebinsky (avpog)

thanks, it so simple that I forgot about it :)

Legacy ID: #4223570 Legacy Poster: Alexander Pogrebinsky (avpog)

Oh, sorry, but saxon8.jar contains META-INF\services\javax.xml.transform.TransformerFactory file with net.sf.saxon.TransformerFactoryImpl inside. So if I place saxon8.jar into classpath JVM pick it up anyway. How to manage this issue? may be by placing in rigth classlader like war module one.

Legacy ID: #4223630 Legacy Poster: Michael Kay (mhkay)

If you set the system property javax.xml.transform.TransformerFactory to the Xalan factory, that should override the classpath search.

Legacy ID: #4223714 Legacy Poster: Alexander Pogrebinsky (avpog)

thanks a lot