Announcement Announcement Module
Collapse
No announcement yet.
can I use jmx & spring together? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • can I use jmx & spring together?

    Hello,
    I'd planning to use jmx for a new project but I also need basic framework support for dependency control, lifecycle management and some configuration. I'm new to spring and I was wondering if it supports or integrates with jmx, and if so to what degree?. Has anyone tried this or have an example?
    Thanks.

  • #2
    There is initial support for exposing Spring bean as JMX managed beans in the sandbox. Final support is targeted for the 1.2 release. Currently, the sandbox version support attribute-based exposing of bean properties and seamlessly integrates with a JMX server available in your application server.

    The final JMX support is something that's going to pretty cool IMO since it allows you to really transparently expose your beans, without having to code to a bunch of classes required by the JMX spec (Spring does this for you).

    Alef

    Comment


    • #3
      Thanks Alef,
      We don't have an application server and we don't need a heavyweight one for our purposes. That was precisely the reason I was interested in spring. Looking forward to 1.2. Any pointers to where I can find a roadmap for spring?
      Thanks,
      Ilker

      Comment


      • #4
        When not using an application server the reference implementation could help you or you could mx4j which is great as well.

        I'm not sure when 1.2 is planned. Work is still being done on 1.1, 1.2 probably won't appear until mid Q4.

        I'll try to ping Rob today (the guy implementing JMX) to see if he can elaborate.


        Alef

        Comment


        • #5
          Originally posted by Alef Arendsen
          There is initial support for exposing Spring bean as JMX managed beans in the sandbox. Final support is targeted for the 1.2 release. Currently, the sandbox version support attribute-based exposing of bean properties and seamlessly integrates with a JMX server available in your application server.

          The final JMX support is something that's going to pretty cool IMO since it allows you to really transparently expose your beans, without having to code to a bunch of classes required by the JMX spec (Spring does this for you).

          Alef
          Where is the "sandbox" - how can I check out the current implementation?

          Thanks,

          Scott

          Comment


          • #6
            The sandbox is located in the spring module in the sourceforge CVS. There are details on how to check out the CVS at
            http://www.sf.net/projects/springframework (click the CVS link)

            cheers,

            Alef

            Comment


            • #7
              To expand on what Alef has already written the Spring JMX features will first be released in 1.2, although I am not exactly sure when that is planned for release.

              A substantial amount of JMX code already exists in the sandbox (which is a special folder in the Spring CVS repository). You can check this code out from CVS and try out Spring JMX now.

              The current feature set mainly focuses on exposing Spring beans to JMX automatically. There are a huge range of features already available for this and you will find some basic docs on the Spring Wiki at: http://opensource.atlassian.com/conf...DOC/Spring+JMX.

              I recently added some new features to support JMX usage in environments where there is no default JMX server. When using JBoss for instance Spring JMX will auto locate the JMX server for JBoss and use that. In a non JMX enabled environment you can use the MBeanServerFactoryBean to create an MBeanServer instance for you - all you need is a JMX implementation on the classpath.

              Also added recently was an autodetect capability so that beans that are marked with a particular attribute, using Commons Attributes, are automatically picked up and exposed to JMX with very little config.

              Finally you will also find features to create proxies to JMX resources such that you can access a JMX managed resource via the proxy, without having to interact with the MBeanServer directly.

              I still need to enhance the specification adherence and there have been requests to support JMX 1.0 so I want to look at how we can go about doing that without losing out on JMX 1.2 features.

              The next step in implementation is to extend the options for exposing beans to include XML based management information descriptors, to add JSR-160 support and to create an AdaptorHost concept so that we can host some common adaptors for you automatically.

              After this that will pretty much cover all the features that will be going into the 1.2 release of Spring JMX as far as bean exposure goes. The next step is to look at JMX enabling Spring itself. One of the core goals here is to allow you to modify a configuration and have this persist back to your config file, although this is dependent on another part of the planned feature set for 1.2.

              We are getting some good feedback on this already. I am trying in between coding to flesh out the docs in the Wiki, but you can find most examples in the unit test suite for this which is quite comprehensive.

              I would really appreciate feedback on this as well as feature suggestions and bug reports. If you can suggest features on the mailing list and post any bugs to Spring JIRA that would be superb.

              Cheers,

              Rob

              Comment


              • #8
                Rob,

                Great work on the JMX code. Is there any plan to support the other lifecycle interfaces that Spring provides, namely DisposableBean? I am currently working on glue code that closes the old application context and loads a new one on demand. Whenever I add the Spring JMX management context to my test app, the reload fails but if I leave it out, the reload works. All the stack traces point to existing mbeans that have not been properly removed when the ConfigurableApplicationContext.close() method has been called.

                On another note, I got the JMX support to work in WebLogic which uses a JMX 1.0 implementation. I wrote a custom version of KeyNamingStrategy which replaces the line that calls:

                ObjectName.getInstance(String);

                with

                new ObjectName(String);

                Probably not the most efficient way to get these ObjectNames but it works.

                Thanks!
                ST

                Comment

                Working...
                X