Menu
▾
▴
RE: [Springframework-developer] JMX Support
|
From: Rob H. <ro...@ca...> - 2004-07-21 15:15:04
|
Keith, That would be great, give me a headstart on that! Rob _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Keith Donald Sent: 21 July 2004 16:01 To: spr...@li... Subject: RE: [Springframework-developer] JMX Support Rob, Looking forward to trying this out and reviewing in detail- I can commit some initial JSR160 support if you like, as well as support for various JMX adaptors (e.g the HTML adaptor for managing mbeans using a html interface); this should go hand in hand with a bean (likely a FactoryBean?) to configure a MBeanServer definition in a spring context (your "MBeanServer Hosting" item below.) Keith _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Rob Harrop Sent: Wednesday, July 21, 2004 10:08 AM To: spr...@li... Subject: [Springframework-developer] JMX Support All, Initial JMX Support is in the Sandbox for everyone to try out. The initial feature set that I have is: JmxMBeanAdapter that will expose any of your Spring beans to a running MBeanServer. Beans are exposed via a Map in applicationContext.xml. The JmxMBeanAdapter class supports the notion of metadata assemblers, invokers and naming strategies. The metadata assemblers control how the bean is exposed to the MBeanServer. The default implementation uses reflection and will expose all declared methods as operations and all declared properties as attributes. Also included is source level metadata support so you can choose which methods/properties to expose. This uses the Spring metadata abstraction so any metadata mechanism should be possible, but of course only Commons Attributes is supported. The invokers control how the operations and attributes on the mbean are accessed by the MBean server. The default implementation is reflection-based and I have created a CGLIB implementation as well. JMX 1.2 states that attributes can no longer be accessed using operation semantics, that is invoke(), so the implementation explicitly forbids that. Naming strategies control what ObjectName is given to the MBean. There are a few implementations in there already, one that uses the key of the bean Map, one that uses the hashCode and class name and one that allows for the Map key to be mapped to an entry in a properties file. I have also started the basics of proxying for MBean resources with a simple CGLIB implementation. I have some basic tests in the sandbox as well which should give you a good idea of how to get started with the classes. The exception hierarchy isn't as nice as I would like but I can modify as I go through and clean up the code. My plans for the rest of the week are to add a metadata naming strategy to read the ObjectName from source level attributes, finish the proxying support including a JDK proxy and a FactoryBean and really improve the test suite. My feeling is that the current feature set is pretty usable, I just need to polish up the tests and documentation. Beyond this I will be adding support for: - Constructors. I will take a good look at the how instancing semantics fit between JMX and Spring at this point as well. - Notifications. Need to have a good think about this, but I will start with attribute change notifications and then look at linking in with the event model to publish JMX notifications. - MBean Server Hosting. I will create a simple bean to host an MBeanServer so that your application doesn't need to create one manually - Manual MBean Support. I will add support to auto register any manually created MBeans. - Additional Metadata Support. In this way you can specify your management interface metadata in XML, DB etc - JSR Frenzy - There are a bunch of JSR's that are JMX related that could potentially be integrated into Spring. Rob |
