abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ugo cei <u....@sourcesense.com>
Subject Re: Using Abdera in a Confluence plugin
Date Thu, 15 May 2008 12:56:19 GMT

----- 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