Marc Saegesser wrote:
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> >* Java asked the webapp class loader to find the
> > controller servlet class
> >* The webapp class loader did not find the class
> > so it delegated to the shared class loader
> >* The shared class loader (which reads from $CATALINA_HOME/lib
> > in Tomcat 4.0 -- the corresponding loader in Tomcat 3.2 reads
> > from the system classpath) and finds your class
> >
> > Now, when your controller servlet calls Class.forName(), it
> > starts from its
> > *own* class loader, and looks either there, or upwards. Of
> > course, if your
> > components are under WEB-INF/classes or WEB-INF/lib, they are not
> > visible ...
>
> The Java2 class loading model is for a loader to "delegate first" to it's
> parent loader. Only if the parent loader (that also delegates first to it's
> parent) can't find the class will the original loader try to load it.
>
> The description above shows the webapp loader attempting to load the class
> first and only delegating if that fails. Is this really the case?
>
Sorry ... I should have been more explicit here.
You're right about the normal delegation model for Java2. However, the Servlet
2.3 Spec (Proposed Final Draft) gives a servlet container the option to "look
before delegating" -- see Section 9.6.2. Tomcat 4.0 does this.
The intention of this language is that you can have version X of a library
installed as a shared resource, and version Y of the library available in
WEB-INF/lib. In the 2.3 model, Y will override X. In the standard delegation
model (i.e. Tomcat 3.2) you'd get the classes from X no matter what you did.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
