XOM API for Processing XML with Java

[Michael Abato <mrabato AT earthlink.net>]

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