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