3 Replies Latest reply on Oct 12, 2004 3:00 PM by damien

    MBeanServer in client JAR

    damien

      I'm testing out JBoss 3.2.6 RC2, moving from JBoss 3.2.3. We've got some client processes which connect to the app server, and internally use the MX4J JMX implementation.

      We were using jbossall-client.jar with JBoss 3.2.3. However, the 3.2.6 version of that same JAR file includes the JBoss MBeanServer implementation. It would be nice to avoid the conflict that this causes with our existing JMX implementation, so I am wondering what the JBoss implementation is for on the client side?

      I'd like to understand what it is used for before I get rid of one or the other MBeanServer implementations.

      -- Damien

        • 1. Re: MBeanServer in client JAR
          dimitris

          I'm not aware why the change was made, just before 3.2.4 was out. Looking into the CVS tree version 1.160.2.155 of build/build.xml:

           <!-- Copy the generated client libraries -->
           <mkdir dir="${install.client}"/>
           <copy tofile="${install.client}/jmx-client.jar"
           file="${_module.output}/lib/jboss-jmx-core.jar" />
          


          jmx-client.jar is then included as part of jbossall-client.jar.

          What's the conflict you get when running your client application?

          I guess the easy solution is to pick the jboss client jars individually,
          e.g. jboss-client.jar + jboss-common-client.jar + ..., or remove
          org.jboss.mx.* & javax.management.* from jbossall-client.jar

          • 2. Re: MBeanServer in client JAR
            starksm64

            There are objects that can be pulled down via jmx calls that need the jboss jmx implementation classes. Not all of the org.jboss.mx classes in the jbossall-client.jar are actually needed so it can be trimmed down depending on your usage.

            • 3. Re: MBeanServer in client JAR
              damien

              Ok. Thanks for the input. I think the answer for me is only including the JARs that I need.

              Otherwise, we'll have to bring the dom4j.jar dependency into our client classpaths. That is actually how we found out about this - our client processes wouldn't start because of a NoClassDefFound error. The JBoss JMX stuff depends on dom4j.