Status Report: "Sealing Violation" Problems With Xerces

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Several people have reported difficulties with Tomcat 4.0b1when trying
to put xerces.jar (or another XML parser) in the WEB-INF/lib directory.
In theory, this should work fine -- Tomcat 4.0 implements the new
servlet 2.3 recommendation that local classes override ones from the
shared library classpath (i.e. all the JAR files in $CATALINA_HOME/lib,
which includes the JAXP 1.1 reference implementation required by
Jasper).

The good news:  Thanks to the help of several folks in the Turbine and
Jetspeed communities, I was able to accumulate enough test cases to
isolate where the problem is occurring.  It's definitely a problem in
the Tomcat 4.0 web app class loader, which is implementing the "local
override" functionality inconsistently.

The bad news:  Several simple fix attempts have not succeeded in making
this work -- it's going to take some more digging, but I'm confident
that it can be solved within a few days.  At that time, I will be asking
people to try a nightly build with the proposed fix, to ensure (a) that
it fixes the problem for everyone encountering it; and (b) that it does
not introduce other wierd things related to class loaders.

For those interested in the gory details, the problem is in
StandardClassLoader.findClass(), which delegates to the parent class
loader prior to checking the local repositories (I'm not sure this is
really correct behavior -- hence the need for some research).  Consider
a class like org.xml.sax.EntityResolver, which correctly exists in both
Xerces and Crimson.  If the Crimson version of this class is loaded
first, any attempt to load other org.xml.sax.* classes from Xerces will
fail with a package sealing exception, because crimson.jar is sealed.

Knowing what's wrong is the biggest part of the debugging effort -- now,
it's just a matter of finding the right solution.

Craig McClanahan

(Jon, feel free to share this status report with the Turbine and
Jetspeed lists, and anyother list you know of that has reported this
issue).

Re: Status Report: "Sealing Violation" Problems With Xerces

[James Duncan Davidson <du...@x180.net>]

on 2/7/01 6:05 PM, Craig R. McClanahan at Craig.McClanahan@eng.sun.com
wrote:
> For those interested in the gory details, the problem is in
> StandardClassLoader.findClass(), which delegates to the parent class
> loader prior to checking the local repositories (I'm not sure this is
> really correct behavior -- hence the need for some research).  Consider
> a class like org.xml.sax.EntityResolver, which correctly exists in both
> Xerces and Crimson.  If the Crimson version of this class is loaded
> first, any attempt to load other org.xml.sax.* classes from Xerces will
> fail with a package sealing exception, because crimson.jar is sealed.

By default, the behavior recommended by the docs -- and the one exhibited
here is correct for most cases as the classes that implement the same "name"
should be in totally different class loaders that are siblings and are not
in a parent-child relationship. The problem that you describe here is
symptomatic of some sort of parent-child relationship where differing
classloaders are resolving sometimes to the same classloader and sometimes
to different classloaders (often seen when there are subtle versioning
differences).

At least that's my two cents from having been around the class loader block
a few times.

.duncan
-- 
James Duncan Davidson
http://x180.net/                                             !try; do();