Bug 1081511

[From RHQ Bugzilla 863449]

Suppose I have a plugin A with a dependency on plugin B. Plugin B has a type with a normal, shared classloader, but plugin A has a runs-inside type (running inside a type in plugin B) where classLoader="instance" is metadata set on that A type.

Further assume that plugin A has a <depends> on a plugin C and plugin B does NOT have a <depends> on plugin C.

When a resource component of type A is given a classloader, it is missing plugin C classes.

Below is the relevent code where the bug is. We'd need to add something to that second inner-else clause in ClassLoaderManager.obtainResourceClassLoader - somehow being able to inject plugin C classloader. Right now you see the parent classloader is only going to be plugin B's classloader (which again doesn't have plugin C as a dep) and the new created classloader will only get plugin A jar. Somehow, plugin C needs to be added to the final resource classloader.

} else if (resourceClassLoaderType == ClassLoaderType.INSTANCE
    && parentClassLoaderType == ClassLoaderType.SHARED) {

    // Resource wants its own classloader, even though the parent is willing to share its classloader.
    // If we reached the top of the resource hierarchy, our resource's new classloader needs to follow
    // up its plugin classloader hierachy. If we are not at the top, the resource is running inside
    // its parent resource and thus needs to have that parent resource's classloader. 
    if (isParentTopPlatform) {
        resourceCL = createClassLoader(this.pluginNamesUrls.get(resourcePlugin), additionalJars,
            obtainPluginClassLoader(resourcePlugin).getParent());
    } else {
        resourceCL = createClassLoader(this.pluginNamesUrls.get(resourcePlugin), additionalJars,
            obtainPluginClassLoader(parentPlugin));
    }

******************************************************************

one workaround that I think might work is for the plugin A to add "useClasses=true" to its <depends plugin="C" useClasses="true">. This assumes the plugin A components do not actually need to use classes from plugin B - if so, this bug will be hit. You will have to do something like actually package plugin C's jar (and its dependencies) directly in plugin A's /lib directory.