Bug 638956 - agent needs to rely on JRE JAXB, no longer ship its own
Summary: agent needs to rely on JRE JAXB, no longer ship its own
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Agent
Version: 4.0.0
Hardware: All
OS: All
low
medium
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-30 13:35 UTC by John Mazzitelli
Modified: 2014-06-27 20:42 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-27 20:42:44 UTC
Embargoed:


Attachments (Terms of Use)

Description John Mazzitelli 2010-09-30 13:35:44 UTC
See https://fedorahosted.org/pipermail/rhq-devel/2010-September/000279.html for a full thread discussion.

I'm thinking we need to strip out the JAXB libs found in the agent's lib/endorsed location. Now that we are on JRE 6 (and no longer running on JRE 5), I think the way we have it is going to cause problems now (I think its causing problems already - see that thread link above)

It'll also mean changing the default root classloader regex so it doesn't hide jaxb (we need it to be loadable from the boot classloader now).

This involves classloader issues - we'll need to take our time and test this thoroughly to make sure that's the correct solution and won't break anything.

Comment 1 John Mazzitelli 2010-09-30 15:05:48 UTC
this is why we put JAXB 2.1 libs in the agent's endorsed directory (from the agent's ant script that bundles the agent distro):

      <!-- The JAXB jars need to go in endorsed, since we use JAXB 2.1, which would cause conflicts with
           JAXB 2.0, which is bundled with Java 6, when running under Java 6. JAXB 2.1 depends on
           Activation 1.1, which we also need to include, in order to remain compatible with Java 5,
           which bundles Activation 1.0. -->
      <fileset dir="${settings.localRepository}" id="endorsed.classpath.fileset">
         <include name="javax/xml/bind/jaxb-api/${jaxb-api.version}/jaxb-api-${jaxb-api.version}.jar"/>
         <include name="com/sun/xml/bind/jaxb-impl/${jaxb-impl.version}/jaxb-impl-${jaxb-impl.version}.jar"/>
         <include name="javax/activation/activation/1.1/activation-1.1.jar"/>
      </fileset>

Comment 2 John Mazzitelli 2010-10-01 12:58:34 UTC
from Bala Nair on the rhq-devel mailing list:

"I believe jdk 6 u4 and later is bundled with jaxb ri 2.1.3 - u21 is the current release of java 6, so maybe you're ok."

Comment 3 John Mazzitelli 2010-10-01 19:45:56 UTC
from Bala Nair on the rhq-devel mailing list:

> We removed the jaxb references from the root-plugin-classloader-regex in
> agent-configuration.xml, removed the endorsed libs from the agent
> startup and changed our instance classloader back to shared.  That seems
> to fix the issue - we can now connect to the managed resource via
> jax-ws.

Comment 4 Bala Nair 2010-10-01 20:26:49 UTC
Issue:

A linkage exception is thrown when we tried to use an instance classloader for our plugin's resource component class, which uses jax-ws to connect to its managed resource.  Exception was:

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

We appear to be getting class leakage between our plugin classloader and the boot classloader, both loading jaxb classes.  


Root cause, from John Mazzitelli on the rhq-devel mailing list:

We actually put our own JAXB API in the agent/lib/endorsed directory because we needed JAXB and we needed to support JRE 5 (which didn't ship with JAXB). We install those JAXB libraries as endorsed libraries via -Djava.endorsed.dirs (see rhq-agent.sh for where we do that). In our root classloader regex, we hide those JAXB classes because we didn't want to clash with other plugins that also want to use their own external JAXB impl. This should allow other plugins to ship their own JAXB libraries and be able to use those (again, because back on JRE5 we didn't have the JRE to supply them to us).

But when you load the Web Services class, they come from the bootstrap classloader - and when their signatures reference that JAXBContext API, its ALSO comes out of the bootstrap classloader because that is now in the the built-in JRE libs! This is probably causing the problem. But we shouldn't be doing this "JAXB installed as an endorsed library" now anymore. We are moving to JRE 6, and since it has JAXB built-in we should not be shipping these JAXB libraries and installing them ourselves (which was only necessary for JRE5 runtimes)


Our solution:

- removed the jaxb libraries from endorsed lib (jaxb 2.1 ships with jdk6 u4 and later)
- modified the rhq-agent.plugins.root-plugin-classloader-regex in agent-configuration.xml to no longer exclude the jaxb classes from plugin classloaders
- changed our server back to using shared classloader 
- removed ClassLoaderFacet from resource discovery

Comment 5 Jay Shaughnessy 2014-06-27 20:42:44 UTC
Seems this is resolved.


Note You need to log in before you can comment on or make changes to this bug.