[Springframework-developer] Revising the JMX support

[Juergen H. <ju...@in...>]

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