Ugo,
Wouldn't this work;
return ServiceUtil.class.getClassLoader ();
Cheers,
-- Chris
On May 15, 2008, at 7:56 AM, ugo cei wrote:
----- 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
