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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
