commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <rdon...@apache.org>
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:

<snip>

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

<snip>

> 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
classloader?

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
suitable. 

> 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.

LOL

> 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.

+1

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message