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
