Sylvain:
X-posted to the Saxon list as well.....
> I remember having such problems with older versions of Saxon, and the
> culprit was the AElfred parser that comes bundled with Saxon which is
> limited to saxon's needs (hence why it's read-only).
The latest version of Saxon (7.9) does not include AElfred any more. AElfred
is now a separate download, which I am not using, so that part is not an
issue.
> Two trick solve the problem:
> - remove the META-INF/services/java.xml.parsers.* files in the saxon jar
With AElfred not included, this entry is no longer in the jar file. However,
there is a java.xml.transform.TransformerFactory entry in META-INF/services
with the value of "net.sf.saxon.TransformerFactoryImpl". I think this entry
is the one that causes the Saxon dom to be used.
> - rename saxon.jar to zsaxon.jar so that it comes after xerces in the
> classpath (highly servlet engine dependent though).
Already did that, but with the latest versions (and Tomcat), it still seems
that you need the Xalan jar file ahead of the Saxon one, or the Saxon read-
only DOM still gets selected.
It looks to me that it's the java.xml.transform.TransformerFactory entry in
META-INF/services that controls this. With the Xalan jar first the value
points to the Xalan implementation of the TransformerFactory implementation,
which in turn grabs the Apache DOM implementation instead of the troublesome
Saxon one. The issue with doing this (even though it works...yay!) is that
I'm not sure how much of Xalan versus Saxon is being used for XSL
transformations when you use the Xalan transformer factory reference.
Any insight?
Thanks!
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
|
