Description of problem: In the RHQ server, the CLI code can theoretically be invoked with different context classloaders. This obviously depends on the thread that invokes the code in question. It is generally not guaranteed that context classloader will be the same from invocation to invocation. The interface simplifiers inside CLI generate custom classes on the fly and place them inside the context classloader. Such dynamically generated class is then used to generate a dynamic proxy that is configured to reside in the same classloader as the original interface. Because the classloader of the original interface and the context classloader can be different, the creation of the dynamic proxy might fail because the dynamically created class will not be visible in the original classloader. Version-Release number of selected component (if applicable): 4.3.0-SNAPSHOT How reproducible: with difficulties Steps to Reproduce: 1. checkout and build https://github.com/metlos/rhq-xmpp 2. Install the plugin into RHQ server 3. Configure it following the instructions in this video http://vimeo.com/35730049 4. Connect to the chat and try sending "var r = ProxyFactory.getResource(10001);" Actual results: IllegalArgumentException complaining about a class not being visible from classloader Expected results: CLI statements working as expected Additional info:
master: http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=c9cc6ed13db6d9d246611f627323abc86bd3f461 Author: Lukas Krejci <lkrejci> Date: Tue Jan 31 19:11:25 2012 +0100 [BZ 786194] - Make sure to set the correct context classloader when simplifying the interfaces for the LocalClientProxy.
Not quite sure how this ended up as CLOSED:UPSTREAM. Also it doesn't seem to have gone through a verification step so setting it back to ON_QA so it can be verified in master/RHQ4.3
Putting this under the correct tracker.
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.