tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Re: Lutris_Kelp: [Fwd: What Do We Do With The User's Classpath?]
Date Thu, 20 Jul 2000 05:53:54 GMT
The method of delegating class loading below has one potential gotcha.
If you have X virtual web hosts, each with Y webapps, and there is a
cool library Z which web publishers put in each of their web app directories...

Each web app class loader could have an instance of the classes from
library Z, or X*Y instances of the same class resident in the JVM stack.
This could significantly increase JVM stack usage and tomcat scalability.

I see the need for delegation of class loading, but I don't think this
should be the default behaviour.  By default Tomcat should follow the
normal class loading scheme where the webapp lib/classes directories
are checked last.  But if for some reason a customer needed a different
version of a library you could configure server.xml to allow a single
package to be loaded by the web app classloader overriding the
parent class loaders.

<Context ...>
  <overload package=""/>



"Craig R. McClanahan" wrote:
> > [snip]
> > I looked at FileClassLoader and only have the following comment:
> >
> > The general order of searching (in getResource, loadClass,
> > getResourceAsByteArray) is backwards from the delegation model.  You should
> > check cache, then check parent, then check yourself, and then raise
> > ClassNotFoundException.  It is this delegation scheme that guarantees that
> > classes from less trusted sources don't override classes from more trusted
> > sources.  This model may also improve performance.  Since most of the
> > classes that are loaded are java system and extension classes, most class
> > loading can be resolved before any application level class loader has to
> > search thru its class path looking for the class.  I realize that your class
> > loader has the notion of restricted and system classes, but my gut tells me
> > that mechanisn isn't as clean the delegation scheme.  But then again, maybe
> > it solves other issues that I'm just not aware of...
> >
> I agree that it is backwards from the current Java2 delegation model.
> However,
> consider the following use case:
> * System manager has installed version X of the FooBar JDBC driver
>   as a shared library (on the system class path).
> * A particular application installed in this container installation
> requires
>   some patches that were applied in version Y of the FooBar JDBC
>   driver, so the developer included this jar in WEB-INF/lib.
> * If the traditional delegation model, is followed, none of the version
> Y
>   classes are used (they have the same class names, after all), so the
>   container vendor gets a bug report "your *&*&(*$&*#(& container
>   won't load my classes even though they are in the WEB-INF/lib
> directory!!!"
>   Trying to blame the sysadmin for installing version X as a shared
> library
>   isn't going to get us very far, because she's got existing
> applications
>   that require it, and she sees no need to duplicate it on all the
> existing
>   web-apps just for this new app to work.
> * If the existing Catalina model is followed, this one app uses the
> version Y
>   classes and everyone else continues to rely on the existing shared
>   version X driver installed in the container.  Peaceful coexistence
> reigns,
>   and everyone lives happily ever after.  :-)
> Ultimately, class loading order is an issue that needs to be addressed
> in the
> 2.3 servlet spec, so that all containers implement it the same way.
> Craig
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Glenn Nielsen    | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |

View raw message