tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aron Kramlik <>
Subject Re: Class loading & classloader visibility test results
Date Wed, 06 Dec 2000 22:47:57 GMT
Thanks Craig, more great info.

I am using Tomcat 3.2 Final Release.
I do not see whereI might have the xml.jar file and so I don't
think I am loading the DOM classes from a different .jar file.
Acrtually, this makes sense since I need to put xml4j.jar in
$TOMCAT/lib (under the CLASSPATH) for my web app to load the

xml4j,jar must not be JAXP-compatible as this was not liked
by Tomcat when I replaced the jaxp.jar and parser.jar files
with it.

I have downloaded, compiled and installed Tomcat 4.0 m4 and
with the same configuration - all my .jar files live under
CATALINA_HOME/webapps/<context>/WEB-INF/lib/*.jar - it fails
as well.

The error might be easier to track down in Tomcat 4.0 so I
will include part of the stack trace:
----- Root Cause -----
java.lang.SecurityException: sealing violation
        at java.lang.Throwable.<init>(
        at java.lang.Exception.<init>(
        at java.lang.RuntimeException.<init>(
        at java.lang.SecurityException.<init>(
        at Method)

Any more ideas?


"Craig R. McClanahan" wrote:
> Aron Kramlik wrote:
> > Rob,
> >
> > This is great information.  I wonder if you could explain
> > why it is that I need to put xml4j.jar file under the $CLASSPATH
> > (i.e. $TOMCAT_HOME/lib) that is loaded by an init() method of
> > a servlet?
> >
> Which version of Tomcat?  There are different issues in each one of them.
> Tomcat 3.1 -- has problems with loading classes from some JAR files under
> WEB-INF/lib that were fixed in 3.2.  There is also a hard coded dependency on
> using the old "Project X" parser (xml.jar) that is included with Tomcat, which
> is on the system classpath because Tomcat needs it.
> Tomcat 3.2 -- you might be suffering from the "class loader ordering" problem,
> which goes like this.  Tomcat 3.2 follows the usual Java "class loader
> delegation model" when searching for classes.  In effect, it always starts from
> the *top* of the hierarchy (the system class loader) instead of the bottom.
> What that means is that if xml4j.jar includes classes with the same names as the
> xml.jar parser (which is likely if they both include things like the DOM
> classes), and if you put xml4j.jar in your WEB-INF/lib directory, the "wrong"
> versions of the commonly-named classes will be loaded.
> Tomcat 3.2 also has a documented requirement for a JAXP-compatible parser.  If
> xml4j.jar is JAXP-compatible, you should be able to just replace the parser
> shipped with Tomcat (jaxp.jar and parser.jar) with xml4j and Tomcat will be able
> to use it as well.
> Tomcat 4.0 -- if you have the "class loader ordering" problem under 3.2, it
> should work correctly to put xml4j.jar into WEB-INF/lib.  The reason is that the
> Servlet 2.3 spec (which Tomcat 4.0 implements) encourages the container to do
> "bottom up" searches of class loaders -- in other words, you should be able to
> run with xml4j.jar in WEB-INF/lib, because the classes will be loaded from there
> first.
> Craig McClanahan

View raw message