Menu
▾
▴
springframework-developer
|
From: Juergen H. <ju...@in...> - 2005-01-13 20:58:48
|
Rob, everybody, I've finally committed the reworked and reorganized JMX support I've been working on for the past couple of days. As announced, I've removed the CGLIB proxy stuff and used the JavaBeans infrastructure for method-to-property detection. In the course of that, I've also removed the option to suppress invalid invocations, because I didn't see the point in this - if a call comes in on a proxy that's supposed to delegate to an MBean, why return null if there's no corresponding MBean attribute or operation? IMO, the correct behavior is to throw an exception in such a case - always. Furthermore, I did some reorganization of the org.springframework.jmx subpackages. I've renamed "proxy" to "access", as it features an MBeanClientInterceptor and MBeanProxyFactoryBean now, analogous to our EJB access classes. I've renamed all "JmxMBean*" classes to "MBean*", as this is expressive enough, in my opinion; after all, everything resides in the "jmx" package anyway. I've kept the adapter host support, but reworked it into direct method calls. The abstract base class for reflection-based adapter access looked quite complicated to me. I usually prefer plain old method calls: certainly not a problem with the JMX RI HtmlAdaptorServer. Therefore, I've reimplemented HtmlAdapterHost that way. Reflection should only be a last resort if we're not allowed to ship the classes that we're coding against. Feedback welcome, of course! If there's something that I accidentally broke or was over-eager to remove (despite there being a good use case for it), please let me know. In general, I like the current structure and feature set. The major gap to close to make the JMX support ready for Spring 1.2 RC1 is the javadoc and documentation - and of course, testing it against a couple of JMX implementations. Juergen |
|
From: Rob H. <ro...@ca...> - 2005-01-14 09:24:07
|
Juergen, That's great news! I'm pretty busy today and over the weekend but I should have some time Monday/Tuesday to finish up the JavaDoc, start on the docs and hopefully put together a sample application showing the different features off. There are a couple of additional features I want to get in the release if possible, but I'll wait untilt after the docs are done so at least we have a release ready. Specifically, I want to try and get JMX 1.0 compat for everything bar the proxy classes (which use JMX 1.2-specific MBeanServerConnection). Plus, I want to get an assembler implementation that uses XML. Rob Juergen Hoeller wrote: >Rob, everybody, > >I've finally committed the reworked and reorganized JMX support I've been >working on for the past couple of days. > >As announced, I've removed the CGLIB proxy stuff and used the JavaBeans >infrastructure for method-to-property detection. In the course of that, I've >also removed the option to suppress invalid invocations, because I didn't >see the point in this - if a call comes in on a proxy that's supposed to >delegate to an MBean, why return null if there's no corresponding MBean >attribute or operation? IMO, the correct behavior is to throw an exception >in such a case - always. > >Furthermore, I did some reorganization of the org.springframework.jmx >subpackages. I've renamed "proxy" to "access", as it features an >MBeanClientInterceptor and MBeanProxyFactoryBean now, analogous to our EJB >access classes. I've renamed all "JmxMBean*" classes to "MBean*", as this is >expressive enough, in my opinion; after all, everything resides in the "jmx" >package anyway. > >I've kept the adapter host support, but reworked it into direct method >calls. The abstract base class for reflection-based adapter access looked >quite complicated to me. I usually prefer plain old method calls: certainly >not a problem with the JMX RI HtmlAdaptorServer. Therefore, I've >reimplemented HtmlAdapterHost that way. Reflection should only be a last >resort if we're not allowed to ship the classes that we're coding against. > >Feedback welcome, of course! If there's something that I accidentally broke >or was over-eager to remove (despite there being a good use case for it), >please let me know. In general, I like the current structure and feature >set. The major gap to close to make the JMX support ready for Spring 1.2 RC1 >is the javadoc and documentation - and of course, testing it against a >couple of JMX implementations. > >Juergen > > > >------------------------------------------------------- >The SF.Net email is sponsored by: Beat the post-holiday blues >Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. >It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > |
|
From: Juergen H. <ju...@in...> - 2005-01-14 10:25:09
|
Rob, OK, next week is soon enough! I intend to release Spring 1.1.4 on Sunday, but the JMX support is not affected by this anyway. Forgot to mention a further important renaming: I've renamed MBeanAdapter to MBeanExporter, as it plays a role similar to the exporters in our remoting support, and to avoid naming confusion with the "adapter" package (HtmlAdapterHost etc). I guess for Spring 1.2 RC1, support for JMX >= 1.2 is a reasonable goal. Of course, if we manage to get stable support for JMX 1.0 too, that would be great, but it's not a requirement for RC1. And it's perfectly acceptable that some features will require JMX 1.2 (in particular if it's not the export but just the access to MBeans)! Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Rob Harrop Sent: Friday, January 14, 2005 10:22 AM To: spr...@li... Subject: Re: [Springframework-developer] Reworked and reorganized JMX support Juergen, That's great news! I'm pretty busy today and over the weekend but I should have some time Monday/Tuesday to finish up the JavaDoc, start on the docs and hopefully put together a sample application showing the different features off. There are a couple of additional features I want to get in the release if possible, but I'll wait untilt after the docs are done so at least we have a release ready. Specifically, I want to try and get JMX 1.0 compat for everything bar the proxy classes (which use JMX 1.2-specific MBeanServerConnection). Plus, I want to get an assembler implementation that uses XML. Rob Juergen Hoeller wrote: >Rob, everybody, > >I've finally committed the reworked and reorganized JMX support I've been >working on for the past couple of days. > >As announced, I've removed the CGLIB proxy stuff and used the JavaBeans >infrastructure for method-to-property detection. In the course of that, I've >also removed the option to suppress invalid invocations, because I didn't >see the point in this - if a call comes in on a proxy that's supposed to >delegate to an MBean, why return null if there's no corresponding MBean >attribute or operation? IMO, the correct behavior is to throw an exception >in such a case - always. > >Furthermore, I did some reorganization of the org.springframework.jmx >subpackages. I've renamed "proxy" to "access", as it features an >MBeanClientInterceptor and MBeanProxyFactoryBean now, analogous to our EJB >access classes. I've renamed all "JmxMBean*" classes to "MBean*", as this is >expressive enough, in my opinion; after all, everything resides in the "jmx" >package anyway. > >I've kept the adapter host support, but reworked it into direct method >calls. The abstract base class for reflection-based adapter access looked >quite complicated to me. I usually prefer plain old method calls: certainly >not a problem with the JMX RI HtmlAdaptorServer. Therefore, I've >reimplemented HtmlAdapterHost that way. Reflection should only be a last >resort if we're not allowed to ship the classes that we're coding against. > >Feedback welcome, of course! If there's something that I accidentally broke >or was over-eager to remove (despite there being a good use case for it), >please let me know. In general, I like the current structure and feature >set. The major gap to close to make the JMX support ready for Spring 1.2 RC1 >is the javadoc and documentation - and of course, testing it against a >couple of JMX implementations. > >Juergen > > > >------------------------------------------------------- >The SF.Net email is sponsored by: Beat the post-holiday blues >Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. >It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Seth L. <set...@gm...> - 2005-01-14 17:58:27
|
> I guess for Spring 1.2 RC1, support for JMX >= 1.2 is a reasonable goal. Of > course, if we manage to get stable support for JMX 1.0 too, that would be > great, but it's not a requirement for RC1. And it's perfectly acceptable > that some features will require JMX 1.2 (in particular if it's not the > export but just the access to MBeans)! JMX 1.0 would be very nice to have. IIR, Tomcat 5.0.x still uses JMX 1.0. It seems that dropping in the newest version of mx4j into Tomcat upgrades it just fine. But to have out of the box support for TOmcat 5.0.x would be very nice. Otherwise, a note in the documentation on how to upgrade Tomcat to JMX 1.2 would be very helpful. Thanks, Seth -- <a href="http://www.picklematrix.net/foaf.rdf">Seth Ladd's FOAF</a> <a href="http://www.foaf-project.org/">What is FOAF?</a> |
