Bug 1081511 - resource classloader doesn't have all dependencies in it
resource classloader doesn't have all dependencies in it
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin Container (Show other bugs)
JON 3.2
Unspecified Unspecified
high Severity high
: ---
: JON 3.3.0
Assigned To: Thomas Segismont
Mike Foley
Depends On: 863449
  Show dependency treegraph
Reported: 2014-03-27 09:36 EDT by bkramer
Modified: 2014-09-09 13:12 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-09-09 13:12:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description bkramer 2014-03-27 09:36:51 EDT
[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,
    } else {
        resourceCL = createClassLoader(this.pluginNamesUrls.get(resourcePlugin), additionalJars,


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.

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