commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] is setting context classloader correctly mandated by J2EE container specifications?
Date Sun, 13 Mar 2005 09:46:05 GMT
On Sun, 2005-03-13 at 10:40 +1300, Simon Kitching wrote:
> On Sat, 2005-03-12 at 18:20 +0000, robert burrell donkin wrote:


> I've been doing quite a lot of research into this sort of thing over the
> last couple of days.


> The authors appear to have made a huge effort to produce
> incomprehensible specs.

it is certainly difficult that there's a lot of relevant specifications
which use subtle variations of language and definition. i strongly
suspect that the committees produced specially crafted ambiguity in
certain place.

i'm now pulling together a document that i hope should help by pulling
some stuff together. more on this in a separate thread.

> In a normal stand-alone java application, there are three classloaders
> in operation when main(String[]) is called:
>  * the "top-level application class loader", which loads rt.jar etc, and
>    is referred to using "null" as the classloader reference.
>  * its direct child the "extension class loader", which loads stuff
>    from $JAVA_HOME/ext/lib
>  * its direct child the "application class loader", which loads stuff
>    from $CLASSPATH.

is the "top-level application class loader" always the same as the boot

or could JVMs in theory employ four?

(bootclassloader <- top-level-application <- extension <- application)

> So while this section does say that   
>    Thread.currentThread().getContextClassLoader() 
> must return *some* classloader, it doesn't appear to mandate that there
> is a unique classloader created for each deployed component within a
> j2ee environment.

i strongly expect that vendors moved to setting the context classloader
to something they considered suitable before it was mandated. the
problem is that different vendors consider different things to be

> The sentence "Classes loaded by lower class loaders..." seems to be
> talking about per-component classloaders. But the text doesn't
> explicitly say that they must exist. And doesn't say that this
> classloader is what thread context-classloader points to when running
> the component.
> The term "system value class" does not appear to be defined anywhere in
> the document, and damned if I know what it means. The term "top level
> application classes" is not defined either.

> The text isn't even spelled correctly in places. Sigh.


> And besides, commons-logging and commons-beanutils and similar don't
> just need to work in j2ee-compliant frameworks; they need to work in all
> *real-world* frameworks. And as can be seen from replies to my earlier
> question about parent-first vs child-first classloading, popular tools
> such as Resin and Websphere provide deployment options that violate the
> j2ee spec anyway.


- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message