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