tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: Class Loader Triggers
Date Wed, 27 Feb 2002 23:24:12 GMT
Shouldn't the servlet.jar file be placed on the system classpath by the
startup scripts?  The servlet container itself supports a specific version
of the servlet API and the web applications should not be able to pick and
choose which version they wish to use.  Placing these classes on the system
classpath (along with changing the class/resource loading algorithm) would
fix this, because webapps would check the system classloader first.

----- Original Message -----
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Sent: Wednesday, February 27, 2002 6:01 PM
Subject: Re: Class Loader Triggers


>
>
> 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>
>
>
>


--
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