abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: Using Abdera in a Confluence plugin
Date Thu, 15 May 2008 14:50:19 GMT
I'm not familiar with confluence, but the design being used by abdera is
correct and appropriate for the overall majority of cases.  It would be
appropriate, however, to allow an alternative classloader to be set
instead of always assuming text context class loader.

- James

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
> 


Mime
View raw message