Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <3A7F02ED.782499C5@eng.sun.com>
Date: Mon, 05 Feb 2001 11:45:49 -0800
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: Servlet ClassLoader
References: <002701c08f57$eeed7500$0500a8c0@dimon.is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gudmundur Hafsteinsson wrote:

> > | 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!
>
> I agree! This is a very intuitive approach for loading classes
> in webapps, and should be specified without options.
> I don't know the community process that well, and I don't know
> the exact status of 2.3, but is it too late to remove that option and
> make it mandatory?
>

Servlet 2.3 is currently in "Proposed Final Draft" status.  The expert group
is currently considering several clarifications and minor changes.  Feedback
suggesting anything else should be sent to
"servletapi-feedback@eng.sun.com".

On the particular issue of class loaders, this is an area where existing
container implementations differ substantially already.  In fact, there is
no guarantee that any particular container provides for shared JAR files at
all (it is not specified behavior), so it would be difficult to impose this
kind of a restriction without going to the effort to define a lot more about
how shared class loaders work to ensure portability.

Applications that wish to protect themselves from class loader differences
need only follow two rules:
* Don't use any "shared library" capability of your servlet
  container.
* Place all the library JARs you need into WEB-INF/lib.

The challenge, of course, is dealing with things that the container itself
makes available in a shared manner.  For Tomcat, that issue shows up with
the XML parser, which is needed by Jasper to parse TLD files, as well as
pages in XML syntax.  One of the things we definitely need to look at is
migrating the parser that Jasper uses into a separate Jasper-only
classloader, so that it does not "pollute" the class loader space of web
apps.

>
> Reg,
> Gummi Haf

Craig McClanahan