abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <dan.diepho...@mulesource.com>
Subject Re: Using Abdera in a Confluence plugin
Date Fri, 16 May 2008 16:57:38 GMT
We should be using a utility class like this to load classes:


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.


On Thu, May 15, 2008 at 11:01 PM, James M Snell <jasnell@gmail.com> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message