tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Knights" <>
Subject RE: Question: Tomcat 3.2.1 servlet and dynamically loading JAR files
Date Mon, 04 Jun 2001 19:44:48 GMT

Tomcat 3.3 resolves this issue by letting you isolate a web-app's jar files from the container's
jar files. I don't know if the
change is available in 3.2.2 but you might save yourself some work if it is.

The issue in general seems to be an ugly one. From a development point of view it would be
nice if the producers of xml related
packages didn't include in their jar files all the background stuff.
The jdk 1.3 (.1?) release notes contain a description of the new Package package and Sun's
definition of backward compatibility and
the tools they have available for ensuring an app is running with the correct versions of
all related jar files. The now fairly well
known "sealing violation" is an example of this.

It seems to me that if you are deploying an app in a "shared" environment then you have to
include a way for the administrator of
that environment to manage the versions of common packages and make choices as to what apps
they can install based on version

If you really need to do this I'd check out creating a custom class loader .

a) Have your servlet implement an mvc framework so that all work is handled by your own objects
b) call those level "A" objects. For each level A object have it pass its arguments to a level
B object that was created with your
custom class loader.
c) I'd think none of your interfaces could reference any xml related classes.


> I'm trying to deploy a servlet which needs to load specific
> versions of xerces.jar and xalan.jar. Tomcat 3.2.1 bundles jaxp.jar
> and parser.jar under TOMCAT_HOME/lib. These XML JAR files
> contain packages
> and classes which duplicate those in xerces.jar and xalan.jar
> and which
> are incompatible with our versions of xerces.jar and xalan.jar.
> We can modify the Tomcat CLASSPATH so our xerces.jar and xalan.jar
> occur first in the CLASSPATH (thus resolving our servlet
> problem in our
> environment), but we are concerned that our customers will have other
> servlets
> installed besides ours which require xerces.jar and
> xalan.jar, also, or
> some incompatible JAR files which duplicate the XML/XSLT
> packages/classes
> we use. Their versions may differ and be incompatible with
> ours, and we have
> no
> control over what they install. We certainly cannot modify or
> expect our
> customers
> to modify those incompatible JAR files.

View raw message