tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Class Loader Triggers
Date Wed, 27 Feb 2002 23:01:49 GMT

On Wed, 27 Feb 2002, James Carman wrote:

> Date: Wed, 27 Feb 2002 17:09:33 -0500
> From: James Carman <>
> Reply-To: Tomcat Developers List <>
> To: Tomcat Developers List <>
> Subject: Re: Class Loader Triggers
> The documentation states (as you've pointed out) that...
> Therefore, from the perspective of a web application, class or resource
> loading looks in the following repositories, in this order:
>   a.. /WEB-INF/classes of your web application
>   b.. /WEB-INF/lib/*.jar of your web application
>   c.. Bootstrap classes of your JVM
>   d.. System class loader classses (described above)
>   e.. $CATALINA_HOME/common/classes
>   f.. $CATALINA_HOME/common/lib/*.jar
>   g.. $CATALINA_HOME/classes
>   h.. $CATALINA_HOME/lib/*.jar
> Wouldn't it be better to do it this way...
>   a.. Bootstrap classes of your JVM
>   b.. System class loader classses (described above)
>   c.. /WEB-INF/classes of your web application
>   d.. /WEB-INF/lib/*.jar of your web application
>   e.. $CATALINA_HOME/common/classes
>   f.. $CATALINA_HOME/common/lib/*.jar
>   g.. $CATALINA_HOME/classes
>   h.. $CATALINA_HOME/lib/*.jar
> I mean, shouldn't the WebappClassLoader first check with the system
> classloader, then try to load the classes itself, then go to its parent (the
> "shared" classloader)?  Wouldn't that solve our little problem with these
> "trigger" classes?

That would deal with JDK classes, but not others (such as javax.servlet)
that also have to be protected.

>  If this was done, we wouldn't have to worry about
> changing the code if Sun decides to include another standard extension in
> the core libraries in future versions of the JDK.  What do you guys think?

You might want to review Section 9.7.2 of the Servlet 2.3 specification.
It specifically allows the webapp class loader to load first from itself,
to deal with situations like this:
* Your webapp needs version X of a particular class library
  (say, a JDBC driver or an XML parser).
* To ensure that those classes are available, you put the
  corresponding JAR file into /WEB-INF/lib of your webapp.
* But the person managing your servlet container has
  put version Y of the library in a shared repository (or
  as a system extension).
* The version X classes in your webapp would be ignored.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message