On Fri, 2 Feb 2001, Craig R. McClanahan 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.
I've been wondering quite some time: how can this be a "option"? I find
that very disturbing! Wouldn't that make tons of portability problems? The
classloading isn't exactly something that's the easies thing with Java to
grasp, and when things change from container to container, thing start to
get really frustrating..
| 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.
Yes, and this sounds much more sensible. Why not take away the "option"
part of that section?!
I know that you don't personally have the sole responsibility for that
spec, but I just wondered why it is like this!
--
Mvh,
Endre
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
