tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aron Kramlik <akram...@tenzing.com>
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
Parser.

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>(Throwable.java:96)
        at java.lang.Exception.<init>(Exception.java:44)
        at java.lang.RuntimeException.<init>(RuntimeException.java:49)
        at java.lang.SecurityException.<init>(SecurityException.java:41)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:237)
        at java.net.URLClassLoader.access$300(URLClassLoader.java:69)
        at
java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:544)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:203)
        at
org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoader.java:648)
..
..

Any more ideas?

Aron.


"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

Mime
View raw message