Forums » Help »
Ignoring saxon9-dom.jar with DOMResult
Added by Anonymous almost 16 years ago
Legacy ID: #5749401
Legacy Poster: kuruma (kuruma)
Hello, I am trying to add Saxon-B 9.1.0.2 to a web application built using the
Jersey web services package and running on Tomcat, and I am getting a strange error. In
some of the Jersey initialization code (not my own code), it is producing the
application's WADL file and the JDK seems to be choosing to use Saxon as its preferred
XML library. The code apparently tries to use a DOMResult, and I get the message
"Saxon cannot write a DOMResult unless saxon9-dom.jar is on the
classpath". Easy, right? Unfortunately, even after adding the saxon9-dom.jar to
my classpath, I am still getting the error. When I look at the code in SerializerFactory
(where the exception is thrown), I don't see any provision to try to load the classes
from saxon9-dom.jar, just the code: if (result instanceof DOMResult) { throw new
UnsupportedOperationException( "Saxon cannot write a DOMResult unless
saxon9-dom.jar is on the classpath"); } Does this mean that no code that uses
the DOMResult will work with Saxon (regardless of the existence of saxon9-dom.jar)?
Since this code did work before I added saxon9.jar to the classpath, is there a way to
remove Saxon from the "autopick" list, but still manually use it in my
own code (where I need some of its XSLT 2.0 features)? Also, I notice that the line
numbers in the stack trace do not match up with the source files in the .zip that I
downloaded. It this expected? Thanks, Chuck Harris
Legacy ID: #5751293
Legacy Poster: Michael Kay (mhkay)
When the Configuration is initialized, it sets up a list of known
ExternalObjectModels, based on what it is able to load from the classpath at that time.
If saxon9-dom.jar is on the classpath, then the DOMObjectModel will be included in that
list, and the SerializerFactory will then never encounter a DOMResult: see the code a
few lines earlier that starts List externalObjectModels =
pipe.getConfiguration().getExternalObjectModels(); I'm afraid I have no idea why it's
not picking up the ExternalObjectModel for DOM from your classpath; the most likely
explanation is that it's not actually on the classpath that the code is using (some
environments using custom ClassLoaders, in which case anything could happen). Also,
there's not much I can do about applications that use the JAXP factory mechanism to load
an XSLT processor, and then make the implicit assumption that the XSLT processor they
have loaded is Xalan. Failing any other solution, you could remove the META-INF/services
file from the Saxon JAR file (Saxon would then only be loaded if you load it
explicitly.)
Please register to reply
.