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
