----- ugo cei <[EMAIL PROTECTED]> 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
