tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
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 <james@carmanconsulting.com>
> Reply-To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> 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.

Craig


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message