classloader hell

Bala Nair bnairtm at comcast.net
Thu Sep 30 01:55:12 UTC 2010


  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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/rhq-devel/attachments/20100929/601e7962/attachment.html 


More information about the rhq-devel mailing list