2 Replies Latest reply on Apr 28, 2010 1:06 AM by deepak.techie

    JBoss 4.2.3 with JDK 1.6 throws javax.management.NotCompliantMBeanException during deployment

      Hi,

       

      I am working on migration of our product from JDK 1.5 to 1.6.

       

      When we ran the JBoss 4.2.3 server on JDK 1.6 it throws the following exception:

       

       

      [com.j2fe.management.JVMStats] ERROR - Starting failed baseinfradev:service=JVMStats,j2eeApplication=baseinfradev
      javax.management.NotCompliantMBeanException: Class does not expose a management interface: java.lang.Object
      at org.jboss.mx.metadata.MBeanCapability.of(MBeanCapability.java:102)
      at org.jboss.mx.metadata.MBeanCapability.of(MBeanCapability.java:100)
      at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:182)
      at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
      at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
      at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
      at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
      at java.security.AccessController.doPrivileged(Native Method)
      at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
      at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
      at com.j2fe.management.JVMStats.registerJVM(JVMStats.java:55)
      at com.j2fe.management.JVMStats.startService(JVMStats.java:36)
      at com.j2fe.jmx.ServiceSupport.start(ServiceSupport.java:413)
      at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at com.j2fe.jmx.ServiceInvoker.invoke(ServiceInvoker.java:353)
      at com.j2fe.jmx.ServiceInvoker.invoke(ServiceInvoker.java:340)
      at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at com.j2fe.misc.ClassUtils$ReflectionHandler.invoke(ClassUtils.java:215)
      at com.j2fe.jmx.ServiceSupport$ContextExecuter.invoke(ServiceSupport.java:1077)
      at $Proxy62.invoke(Unknown Source)
      at com.j2fe.jmx.ServiceSupport$2.doRetrieve(ServiceSupport.java:1028)
      at com.j2fe.jmx.ServiceSupport$InvokeMethodSecure.run(ServiceSupport.java:1409)
      at com.j2fe.security.JBossSecurityPropagation.execute(JBossSecurityPropagation.java:149)
      at com.j2fe.jmx.ServiceSupport.invoke(ServiceSupport.java:1031)
      at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
      at com.j2fe.jmx.ServiceStarter.execute(ServiceStarter.java:249)
      at com.j2fe.jmx.ServiceStarter.start(ServiceStarter.java:236)
      at com.j2fe.jmx.ServiceStarter.startServices(ServiceStarter.java:167)
      at com.j2fe.jmx.ServiceStarter.startSecureServices(ServiceStarter.java:183)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at com.j2fe.jmx.ServiceInvoker.invoke(ServiceInvoker.java:353)
      at com.j2fe.jmx.ServiceInvoker.invoke(ServiceInvoker.java:340)

       

      The JVMStats class is actually trying to register the ManagementFactory.getClassLoadingMXBean().

       

      Our product gets deployed without any issues on JBoss 4.2.3 with JDK 1.5.

       

      We tried to deploy the same application on JBoss 6.1 M2, we got the same exception as above.

       

      Please let me know if anybody has any clue why this gets failed please let me know.

       

      Thanks,

      Deepak

        • 1. Re: JBoss 4.2.3 with JDK 1.6 throws javax.management.NotCompliantMBeanException during deployment

          Hi,

           

          Finally, I found the cause of the issue. But still need to get a solution.

           

          What I found is that in JBoss App Server before registering any MBean passes the MBean Class to the org.jboss.mx.metadata.MBeanCapability.of(Class mbeanClass). Here it checks whether the MBean is DynamicMBean, StandardMBean, or the Class extends an MBean interface.

           

          I wrote a similar code where I tried to pass the java.lang.ClassLoadingMXBean through this check (downloaded the JBoss 4.2.3 source code).

          Executed the same code with JDK 1.5 and JDK 1.6.

           

          My Observations:

           

          • JDK 1.5: It seems that the sun.management.ClassLoadingImpl is a DynamicMBean since it returns true for the statement DynamicMBean.class.isAssignableFrom(mbeanClass). Also the super class of ClassLoadingImpl is displayed as sun.management.MXBeanSupport

           

          • JDK 1.6: Returns false for the statement: DynamicMBean.isAssignableFrom(mbeanClass). The superclass of ClassLoadingImpl is displayed as java.lang.Object.

           

          • JDK 1.5 covers JMX 1.2 Specification whereas JDK 1.6 covers JMX 1.4 Specification (Did some googling)

           

          • JDK 1.6 now enables us to create our own MXBeans as well as use the ones in the java.lang.management package.

           

          Assumption:

           

          Currently, JBoss 4.2.3 is not able to handle or verify if the MBean is an MXBean. Some code fix is required in the org.jboss.mx.metadata.MBeanCapability.of(Class mbeanClass) method.

           

          I get same error with JBoss 6.x as well.

           

          I can modify the source code and make it functional but our clients use the EAP version. So I am not sure how can this be handled.

           

          Please let me know if you have a solution to fix this issue.

           

          Regards,

          Deepak Chainani

           

          P.S: Please find the attached sample code.

          • 2. Re: JBoss 4.2.3 with JDK 1.6 throws javax.management.NotCompliantMBeanException during deployment

            Finally, I was able to find a workaround to resolve the issue. I had to make some changes in my code.

             

            JDK 6 provides a new StandardMBean constructor to wrap the MXBeans as DynamicMBeans:

             

             

            StandardMBean(T implementation, Class<T> mbeanInterface, boolean isMXBean)

             

            Refer: http://java.sun.com/javase/6/docs/api/javax/management/StandardMBean.html#StandardMBean(T, java.lang.Class, boolean)

             

            This would be only done when the application is deployed on JBoss AppServer, reason being our application is certified to run with Weblogic and WebSphere and it does get deployed successfully without any code changes. 

             

            But, now the only thing I am unable to figure out is ThreadMXBean when registered in the MBean Server, causes the JConsole to disconnect from the MBeanServer. So, as a workaround, currently the ThreadMXBean will not be registered, if the application is deployed on JBoss AppServer.

             

            Please let me know if there is any solution to register the ThreadMXBean.

             

            Regards,

            Deepak