3 Replies Latest reply on Jul 29, 2003 12:47 PM by juhalindfors

    JBoss trying to connect to JDMK 4.2

    naveen123

      JBOSS version : 3.2.1_tomcat-4.1.24
      JDMK 4.2

      Here is the Error :
      Incompatible Management Agent version: java.io.InvalidClassException - javax.management.ObjectName; local class incompatible: stream classdesc serialVersionUID = 1081892073854801359, local class serialVersionUID = -5467795090068647408

      I believe the problem is due to
      Incompatible ObjectName Serialization between JMX 1.1 and JMX 1.2

      http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0301&L=jmx-forum&P=R10502

      Cannot upgrade to higher JDMK...

      Couple of quetions :
      What is a clean way to solve this?
      How does the class loading work? I was under the impression that all the jars placed under the deployment directory are used for that particular application....so placing the Sun's jdmkrt.jar in my applications deployment directory should resolve the problem.

      any pointers would be great.

      thanks,
      naveen



        • 1. Re: JBoss trying to connect to JDMK 4.2

          > How does the class loading work? I was under the
          > impression that all the jars placed under the
          > deployment directory are used for that particular
          > application....so placing the Sun's jdmkrt.jar in my
          > applications deployment directory should resolve the
          > problem.

          No, the JBossMX will be loaded first (hard coded library for the microkernel) and its definition of ObjectName will be used. This is the default deployment behavior.

          How are you using JDMK with JBoss?

          -- Juha

          • 2. Re: JBoss trying to connect to JDMK 4.2
            naveen123

            Thanks for the clarification.
            I am using JBoss as a Client in this case connecting
            to a remote machine where the JDMK management
            agent Server is running and controling services installed on that machine.

            Earlier I used to have a Tomcat 4.0 acting as a Client
            which used to work fine but now that I replaced the Tomcat with JBoss I am running into this problem.
            I tried replacing the JDMK Mgmt Agent Server jar file with newer version of ObjectName.class I get this error.

            "java.io.IOException: HTTP request failed"
            com.sun.jdmk.comm.HttpSendSocket.readNotify(HttpSendSocket.java:160)
            com.sun.jdmk.comm.HttpSendInputStream.read(HttpSendInputStream.java:61)
            java.io.FilterInputStream.read(FilterInputStream.java:66)
            java.io.PushbackInputStream.read(PushbackInputStream.java:120)
            com.sun.jdmk.comm.GenericHttpConnectorClient.sendHttp(GenericHttpConnectorClient.java:351)
            com.sun.jdmk.comm.GenericHttpConnectorClient.invokeRemoteOperation(GenericHttpConnectorClient.java:2360)
            com.sun.jdmk.comm.GenericHttpConnectorClient.invokeRemoteOperationOnInstance(GenericHttpConnectorClient.java:2389)
            com.sun.jdmk.comm.GenericHttpConnectorClient.invokeRemoteOperationNoExceptions(GenericHttpConnectorClient.java:2375)
            com.sun.jdmk.comm.GenericHttpConnectorClient.getMBeanServerId2(GenericHttpConnectorClient.java:588)
            com.sun.jdmk.comm.GenericHttpConnectorClient.connect(GenericHttpConnectorClient.java:477)
            com.appstream.cm.ManagementAgentClient.MACHttpConnector.initializeConnection(MACHttpConnector.java:15)

            • 3. Re: JBoss trying to connect to JDMK 4.2

              So what version of the JMX spec does the JDMK you use implement? I understood from the document you linked to in your original post that there's a bug in JMX RI 1.2 serialization that breaks the serialization compatibility that was set in JMX 1.1 specification.. ? But it doesn't mention JDMK specifically.

              The only work around to the serialization problem I can think of is to build your own connector to communicate between JBoss and JDMK, one that works around the serialization incompatibilites by not trying to use Java's serialization mechanism but passes the relevant instance state via other means (thus avoiding ObjectOutputStream).

              -- Juha