Re: [Springframework-developer] Revising the JMX support

[Rob H. <ro...@ca...>]

Juergen,

I'm happy to remove the CglibJmxObjectProxyFactory. I added that before 
I did the AOP proxy, and it isnt really needed now. Feel free to change 
the way that bean method names are detected, especially if it makes it 
closer to the way other components in Spring work. As for adapters, they 
are often used in standalone applications where no other console 
interface exsists - so a way to define them without coupling the 
application to the implementation class is always useful.

Rob

Juergen Hoeller wrote:

>Rob,
>
>I'm currently revising the JMX support, redesigning the subpackage structure
>etc. (Nothing committed yet.)
>
>I've noticed that we currently have two alternative JmxObjectProxyFactory
>strategies for accessing JMX-managed objects via an MBeanServerConnection:
>CglibJmxObjectProxyFactory and JmxMBeanClientInterceptor. The former proxies
>the full target class of the JMX object on the server, the latter requires
>proxy interfaces to be specified.
>
>Is there a specific reason why we need a separate CglibJmxObjectProxyFactory
>here? It seems to me that we could simply use our AOP ProxyFactory, like
>JmxMBeanClientInterceptor, specifying proxyTargetClass=true and a
>ClassOnlyTargetSource for the target class. This would give us both options
>with one implementation, not requiring the JmxObjectProxyFactory abstraction
>in the first place.
>
>A single MBeanProxyFactoryBean that uses the AOP ProxyFactory underneath
>would be sufficient if my assumption above is correct. It could be derived
>from an MBeanClientInterceptor, analogous to our client-side remoting
>support for Hessian and co. After all, an MBean proxy can be considered a
>proxy for a remote service...
>
>In general, I strongly recommend specifying a proxy interface for such an
>MBean proxy. Like for classic remoting, there is not much point in using the
>server-side implementation class as proxy type on the client side. We can
>still support MBean proxies that automatically use the server-side MBean
>class for a CGLIB proxy, but it should not be the recommended strategy.
>
>A further thing I'd like to revise is the detection of bean properties. The
>entire method name pattern handling is currently implemented in JmxUtils. As
>JMX attributes follow the standard JavaBeans convention, we could use the
>standard JavaBeans Introspector here, analyzing PropertyDescriptors and
>caching Method-to-attributeName resolution. We wouldn't need to do any
>manual method name parsing then.
>
>Finally, is the adapters package intended for usage in applications
>themselves? I guess I haven't fully understood its purpose... Aren't
>adapters usually set up as part of the JMX server? Or is the adapters
>package just intended for test environments? But in a test environment,
>registering a specific adapter directly wouldn't hurt too much... Do we
>really need an abstraction there?
>
>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
>
>
>  
>