This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 535658 (RHQ-2330)

Summary: what happens if a discovery component changes the list of additional classpath URLs?
Product: [Other] RHQ Project Reporter: John Mazzitelli <mazz>
Component: Plugin ContainerAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: cwelton, jshaughn
Target Milestone: ---Keywords: CodeChange, SubBug
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-2330
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-09 11:39:01 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 565628    

Description John Mazzitelli 2009-08-11 11:29:00 EDT
In this method:

   org.rhq.core.pc.plugin.PluginComponentFactory.getResourceClassloader(Resource)

there is this:

            // get the classloader the resource should use
            List<URL> additionalJars = askDiscoveryComponentForAdditionalClasspathUrls(resource, parentContainer);
            ClassLoader cl = classLoaderMgr.obtainResourceClassLoader(resource, parentContainer, additionalJars);
            return cl;

The classloader manager will actually obtain the classloader from the cache if it was already created. So, technically, we are doing extra work by calling "askDiscoveryComponentForAdditionalClasspathUrls" after the first time - but it doesn't hurt anything. However, what happens if the discovery component actually returns a different set of URLs? For example, what if the resource changed the location of its client jars (perhaps a change to plugin configuration?). In this case, it will actually get the wrong classloader back because the cached classloader will have the old classpath URLs, not the new ones. We need a way to say, "this discovery component gave us a different set of URLs from before, throw away the old classloader, remove it from the cache, and create a new one with the new URLs".

Today, I don't think this is a problem because in all the places we use this code flow, the additional classpath URLs will never change (the plugin configuration for jboss-as-5 will never change the location of the jboss install dir, AFAIK). But it is conceivable that some other plugin implementation may change the additional classpath URLs - we'll need to fix this issue if that use-case ever comes up.
Comment 1 Red Hat Bugzilla 2009-11-10 16:02:21 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2330
Comment 2 wes hayutin 2010-02-16 11:52:24 EST
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

keyword:
new = Tracking + FutureFeature + SubBug
Comment 3 wes hayutin 2010-02-16 11:58:12 EST
making sure we're not missing any bugs in rhq_triage
Comment 4 Corey Welton 2010-11-22 13:10:35 EST
Triaged 17-Nov
Comment 5 Jay Shaughnessy 2014-05-09 11:39:01 EDT
The code seems the same but the issue has not come up in over 4 years, it seems.  So, closing.