On Sat, 23 Jun 2001, Craig R. McClanahan wrote:
> > > A) the hierarchy should go:
> > >
> > > SystemCL
> > > | <-- LAYER 1
> > > lib/common CL
> > > / \ <-- LAYER 2
> > > lib/container lib/apps CL
> > > | <-- LAYER 3
> > > WEB-INF/lib << same CL, but with URLs
> > > WEB-INF/classes from both dirs, in this
> > > order...
> >
> > You are absolutely right, that's the intended hierarchy.
>
> One thing you might want to note for the future is that, in servlet 2.3,
> the order of loading in the web-app classloader is specified to be
> reversed from this (i.e. WEB-INF/classes first, then WEB-INF/lib). The
> new spec also permits a web-app classloader to override classes in parent
> classloaders by using a "look then delegate" policy, rather than "delegate
> than look" in the usual Java2 fashion. (Tomcat 4's classloaders do both
> of these things, against a very similar overall hierarchy.)
> Neither of these behaviors is specified for 2.2, so you're pretty much
> free to do what you want. But you should think about implementing similar
> policies now, to improve the portability of apps to containers supporting
> 2.3.
That's why we have pluggable loader - if someone wants such a behavior
he's free to implement a loader. For servlet 2.2 we are not required, and
I'm not going to. And it shouldn't matter anyway - since the common loader
is supposed to have minimal stuff ( javax, other things that should not be
overriden without major risks for security - even if the 2.3 spec would
require them to be - I'm talking about some common utils ).
I believe there are important security issues, but I'm sure the spec took
this into consideration - so probably I'm wrong ( of course, this will be
easy to verify later on, there are quite a few ways someone could try to
exploit a reversed order - but again I'm sure this was taken care of and
it'll be just the fun of trying :-).
Costin
