Ok, we are officially in classloader hell. Our original problem was a class not found exception when trying to use a class defined in an external jar in one of our agent plugins. After some good advice and an explanation of how resource classloaders work, we decided to do the following.
1. declare an instance classloader for our plugin's server class (in the rhq-plugin.xml, server element, classloader="instance" attribute) 2. implement the classloaderfacet in the server discovery component 3. add the relevant jars to the classpath for the server resource component
So now we no longer see the class not found exception. instead we get this:
java.util.concurrent.ExecutionException: java.lang.Exception: java.lang.LinkageError: loader constraint violation: when resolving overridden method "com.sun.xml.internal.ws.client.WSServiceDelegate.createDispatch(Ljavax/xml/namespace/QName;Ljavax/xml/bind/JAXBContext;Ljavax/xml/ws/Service$Mode;)Ljavax/xml/ws/Dispatch;" the class loader (instance of org/rhq/core/pc/plugin/PluginClassLoader) of the current class, com/sun/xml/internal/ws/client/WSServiceDelegate, and its superclass loader (instance of <bootloader>), have different Class objects for the type javax/xml/bind/JAXBContext used in the signature
Is this an instance of class leakage that was mentioned in a previous post? In my reading of LinkageError it sounds like both the bootloader and the pluginclassloader have loaded JAXBContext and because of that the signatures don't match. The other possibility is that the plugin was build using a newer version of jaxb than is present in the jdk.
Question: are the steps we took above correct to implement the classloaderfacet.
Bala Nair
rhq-devel@lists.fedorahosted.org