Bug 863449 - resource classloader doesn't have all dependencies in it
resource classloader doesn't have all dependencies in it
Status: CLOSED WONTFIX
Product: RHQ Project
Classification: Other
Component: Plugin Container (Show other bugs)
4.5
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On:
Blocks: 1081511
  Show dependency treegraph
 
Reported: 2012-10-05 09:46 EDT by John Mazzitelli
Modified: 2014-09-09 13:15 EDT (History)
3 users (show)

See Also:
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:


Attachments (Terms of Use)

  None (edit)
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

Note You need to log in before you can comment on or make changes to this bug.