The rationale for the existing design is that, for the majority of
cases, the context class loader is simply the Right Class Loader. In
WebSphere, for instance, class loaders are hierarchical. Using the
contet class loader ensures that even if the abdera jars are deployed to
the server libs, and therefore loaded by the server's class loader, each
webapp can still have it's own set of extensions in their respective
classpaths. The hierarchy works it all out.
- James
Ugo Cei wrote:
On May 15, 2008, at 3:56 PM, Chris Berry wrote:
Wouldn't this work;
return ServiceUtil.class.getClassLoader ();
I tried this, but I was still having problems with Axiom and Commons
Logging, so I ended up manually copying a bunch of JARs in WEB-INF/lib
and solved my problems (at least temporarily) because I wanted to write
code and not waste time debugging class loader issues.
I'm not keen on committing this change, because I am not that expert
with class loader issues, and would like to hear the rationale behind
the current version before we change it.
Ugo
