Aaron Mulder wrote:
> On Wed, 17 Jan 2001, Craig R. McClanahan wrote:
> > Consider the following scenario - I put a copy of the Postgres JDBC
> > driver (just to show that it's not specific to xml parsers :-) in my
> > shared library directory, because lots of my apps need it. But, one
> > of my webapps needs a different version of the Postgres driver,
> > because it depends on a new feature that was implemented in a later
> > version. So, I put the new driver file in the WEB-INF/lib directory
> > of my webapp, and install it in Tomcat.
> >
> > Under Tomcat 3.2, the newer driver is ignored (because it's got the
> > same class names). Under Tomcat 4.0, the newer driver is respected
> > for that webap -- all others continue to use the shared one.
>
> There is still the "sealing" issue, right?
Not directly ... you can get package sealing problems in stand-alone Java
applications as well, if you try to load classes in a particular package from
more than one JAR file, and the JAR is marked "sealed".
> Certain libraries
> cannot be loaded in more than one ClassLoader, and are marked as "sealed"
> in the Manifest. If you put one in the Tomcat lib and another in the
> webapp lib, you'll get cryptic "Sealing Violation" exceptions. I think
> some of the XML JARs do this (JAXP, perhaps?).
Sealing is one "user error" issue that will cause classloading to fail inside
Tomcat. Another is the fact that a particular class can only see other classes
in its own classloaders, and parents of that classloader, but not children. The
net effect is that some class libraries will NOT work unless you put them inside
WEB-INF/lib, because they need to be able to access other classes specific to
that webapp.
Consider the following scenario:
* Class L is in a shared library ($TOMCAT_HOME/lib for Tomcat)
* Class W is in WEB-INF/classes or WEB-INF/lib/*.jar
* You pass the fully qualified class name of class W to a
method in class L whose job is to instantiate a new object
of this class.
* Class L does essentially the following:
Class wClass = Class.forName(wClassName);
and encounters ClassNotFoundException.
The reason for the exception is that Class L was loaded from the shared library
classloader (which is the parent of all webapp classloaders in Tomcat).
Therefore, it cannot see into the webapp to find class W.
This kind of pattern is very common when parsing XML files -- it's not the
parser itself that has the problem, it's the code you try to run in your SAX
event handlers -- but is not unique to them.
>
> I don't have a full understanding of this, though. Perhaps it
> only breaks if loaded more than once in serial ClassLoaders not parallel
> ones. But I think tomcat's lib is sill in serial with webapp lib, right?
>
I'm not quite sure what you mean by "serial" with the webapp lib, but the
classloader used for $TOMCAT_HOME/lib is a *parent* classloader of the
classloader used for each web application.
>
> Aaron
>
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
