Re: [Springframework-developer] Revising the JMX support

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

It doesn't register the adapter with the MBeanServer which is generally 
requirement for adapters.

Rob

Juergen Hoeller wrote:

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