Re: [Springframework-developer] Revising the JMX support

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

Rob,

Regarding JMX adapters: What does HtmlAdapterHost do that

<bean class="com.sun.jdmk.comm.HtmlAdaptorServer"
      init-method="start" destroy-method="stop">
  <constructor-arg><value>9090</value></property>
</bean>

doesn't? This doesn't couple any implementation classes to the particular
adapter. And I doubt that the application will want to restart or stop the
adapter other than on app startup and shutdown.

And if some special JMX adapter cannot be easily defined that way, we can
provide a special adapter class that performs that starting and stopping.
This doesn't require an adapter abstraction either...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Harrop
Sent: Tuesday, January 04, 2005 2:44 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Revising the JMX support


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
>
>
>
>


-------------------------------------------------------
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