Skip to Content.
Sympa Menu

xom-interest - [XOM-interest] XML1_0ParserConfiguration and java's "endorsed standards" mechanism

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Michael Abato <mrabato AT earthlink.net>
  • To: xom-interest AT lists.ibiblio.org
  • Subject: [XOM-interest] XML1_0ParserConfiguration and java's "endorsed standards" mechanism
  • Date: Fri, 28 May 2004 11:34:32 -0400

I've had trouble for some time using XOM in a J2EE (Tomcat and IBM WAS) context which I've worked around (without really understanding what was going, I'm embarrassed to admit) by making sure XOM is on java.endorsed.dirs (any of the standard ways works). I've finally worked through the relationships among J2EE container implementations, their classloaders, and the J2SE security/classloading/endorsed policy and found the following:

The exception I've seen and worked around looks something like:

org.apache.xerces.parsers.ObjectFactory$ConfigurationError: Provider nu.xom.xerces.XML1_0ParserConfiguration not found
at org.apache.xerces.parsers.ObjectFactory.newInstance(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
etc.

Often, this would even be in a context where no XOM or my application code was in the stack trace! I worked around this by putting xom.jar on java.endorsed.dirs, along with my up-to-date Xerces. Naturally, this left me feeling a bit dirty, but at least everything worked. At least until I had to deploy in a shared environment where I couldn't add xom.jar at such a low, global level.

It turns out, the problem is that Builder.java does

System.setProperty(
"org.apache.xerces.xni.parser.XMLParserConfiguration",
"nu.xom.xerces.XML1_0ParserConfiguration");

which affects the whole VM, regardless of classloader. If a subsequent SAX parser is instantiated anywhere in the VM, it needs XML1_0ParserConfiguration, which may or may not (okay, almost never) be available to it as a result of ClassLoader manipulations. The failure is a ClassNotFoundException which breaks the SAX factory methods. By putting xom.jar on java.endorsed.dirs everyone can see and instantiate the class. In fact, to use Builder.findParser, xom.jar needs to be endorsed due to the J2SE 1.4 SPI rules (http://java.sun.com/j2se/1.4.2/docs/guide/standards/).

My workaround is simply to comment out the setProperty call in Builder.java and rebuild the jar, which seems to work so far, but obviously there should be a public solution.

The code appears to exist in order to prevent XML 1.1 documents from being processed by XOM. Unfortunately, this solution to that problem extends beyond the domain of XOM and stops Xerces from parsing them, and in a way that fails when the Xerces client code doesn't have endorsed access to xom. Perhaps there is a solution that rejects XML 1.1. after the parse rather than before it?

thanks,
Michael Abato




  • [XOM-interest] XML1_0ParserConfiguration and java's "endorsed standards" mechanism, Michael Abato, 05/28/2004

Archive powered by MHonArc 2.6.24.

Top of Page