abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Berry <chriswbe...@gmail.com>
Subject Re: Using Abdera in a Confluence plugin
Date Thu, 15 May 2008 13:56:58 GMT
Ugo,

Wouldn't this work;
       return ServiceUtil.class.getClassLoader ();

Cheers,
-- Chris


On May 15, 2008, at 7:56 AM, ugo cei wrote:

>
> ----- ugo cei <u.cei@sourcesense.com> wrote:
>> This experience taught me that maybe we have just too many components
>> trying to do smart things with class-loading, starting with Abdera's
>> ServiceUtils, Axiom, and Commons Logging. When you try to make all of
>> them work inside a framework that tries to do its own "smart" things
>> with class-loading in order to manage plugins, hells breaks loose.
>> Something to ponder, I think.
>
> Could someone who understand Java class loaders better than I do  
> please review this method from the ServiceUtil class?
>
>
>  /**
>   * Get the context class loader for this thread
>   */
>  public static ClassLoader getClassLoader() {
>    return Thread.currentThread().getContextClassLoader();
>  }
>
> What happens with Confluence (but could happen with other plugin  
> architectures) is that a plugin is loaded by a class loader that is  
> not the webapp one. But the thread that responds to the HTTP request  
> is spawned by the webapp class loader, which knows nothing about  
> classes loaded by the plugin class loader. Thus, whenever the class  
> loader returned by that method is used to load a class which is in  
> the plugin's classpath only, an exception is thrown (and silently  
> swallowed by ServiceUtil#locateInstance, incidentally, which does  
> not help with debugging).
>
> Assuming my analysis is correct, how can we fix this bahavior?
>
>  Ugo
>
> -- 
> Ugo Cei
> Sourcesense - Making sense of Open Source: http://www.sourcesense.com
>


Mime
View raw message