tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
Subject Re: Class Loader Triggers
Date Wed, 27 Feb 2002 22:50:43 GMT
> 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
> "shared" classloader)?  Wouldn't that solve our little problem with these
> "trigger" classes?  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?

I may sound like a broken record here, but you should really look at the
latest code, because somehow things may have changed. Thanks for reminding
me that I'll need to update the docs, BTW.
You still need the some exclusion for JAXP, JNDI (to be safe) and the
servlet API, however.


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

View raw message