Bug 863449

Summary: resource classloader doesn't have all dependencies in it
Product: [Other] RHQ Project Reporter: John Mazzitelli <mazz>
Component: Plugin ContainerAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED WONTFIX QA Contact: Mike Foley <mfoley>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.5CC: bkramer, hrupp, jshaughn
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-09 13:15:16 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 1081511    

Description John Mazzitelli 2012-10-05 09:46:46 EDT
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));
    }
Comment 1 John Mazzitelli 2012-10-05 09:48:28 EDT
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.
Comment 2 Jay Shaughnessy 2014-09-09 13:15:16 EDT
Here it is:

http://tsegismont.blogspot.fr/2014/03/monitoring-mbeans-of-java-ee.html