Announcement Announcement Module
No announcement yet.
JMX MBeans in different packages Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • JMX MBeans in different packages

    So to give some background, I have successfully been able to define an MBeanExporter bean in my Spring configuration that will auto-detect MBeans that implement my defined interface. In other words, if I have created an interface called "SuperMBean", then I can write a class called "Super" that implements "SuperMBean", and then "Super" gets automatically picked up and registered in the MBeanServer, at which point I can do whatever I want with it. Check.

    However, I am running into a problem when my MBeans are located in different packages... Let me explain:

    If I place both "Super" and "SuperMBean" in the package, all is well. But if I place "SuperMBean" in the package and then place "Super" in the my.domain.duper package, suddenly "Super" will no longer get auto-registered by the MBeanExporter bean, even though it is still implementing the interface. Is there a way around this, or am I simply doing something wrong?


  • #2
    Solved the problem by making my MBean into an MXBean (just changed the implemented interface from SuperMBean to SuperMXBean). This also frees me from having to name the concrete class "Super" - as long as it implements the interface, it's good to go.


    • #3
      Well, I thought I had solved the issue. Now I've got a problem with exposed operations... I understand that MXBeans are only supposed to work with a certain set of datatypes ( However, the documentation states that for simple types (String, int), functionality is identical to that of regular MBeans.

      This does not seem to jive with what I am seeing. Spring is indeed finding my MXBean and registering it with the MBeanServer. But it is only exposing methods with no parameters and a void return type. I've got a few methods with String and boolean return types/parameters that do not get exposed as valid operations. If I attempt to programmatically invoke one of these methods, I get an exception thrown into my face about there being "no such method".

      Is this a caviat of MXBeans that I am overlooking, or is Spring not handling this properly? Or am I just missing something really obvious?


      • #4
        Ok, this wasn't (I think) a Spring issue. I just needed a lesson in JMX, and the difference between attributes and operations with MBeans. Those methods that weren't getting exposed were simply being exposed as attributes instead of operations.

        Kind of curious, though, that a method got exposed as an operation when it was a standard MBean, but became an attribute when I made it an MXBean. Either way, it's working as expected now.


        • #5
          JMX MBeans in different packages


          Poseidon cannot do that yet, but it is a very good idea. In fact, one would also like to create a package anywhere and tell Poseidon that in code generation, this resolves to a quite different package prefix.

          This feature wont make it into the next version, however.