We should be using a utility class like this to load classes: http://svn.apache.org/repos/asf/cxf/trunk/common/common/src/main/java/org/apache/cxf/common/classloader/ClassLoaderUtils.java
It has been consistently proven to work on a large variety of appservers and use cases (its been in use over 4 years on a nearly every platform imaginable). I think that depending on the context classloader all the time is probably the wrong thing. I'm not sure if this will solve Ugo's issue, but it could save us pain down the road. Dan On Thu, May 15, 2008 at 11:01 PM, James M Snell <[EMAIL PROTECTED]> wrote: > 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 >> >> -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog
