cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Soltysik, Seumas" <Seumas.Solty...@iona.com>
Subject RE: JMX Changes
Date Fri, 02 Feb 2007 16:09:48 GMT
Willem wrote:
"We can get it simple in this way.
I think we can leverage AOP to provide configureable managed component 
which we can decide to call registerMBean or not when it do the post 
construction work without hard code."

Given that not all objects are instantiated using Spring or something similar, for instance
ServerImpl in ServerFactoryBean, then I am not sure how you are going perform post construction
AOP. The other thing to consider is that we want to provide a simple mechanism for users to
register their own code as MBeans in a simple way without relying on spring or other frameworks.
Regards,
Seumas

-----Original Message-----
From: Willem Jiang [mailto:ning.jiang@iona.com]
Sent: Friday, February 02, 2007 4:06 AM
To: cxf-dev@incubator.apache.org
Subject: Re: JMX Changes


Hi Seumas,

Please see my comments in the mail.

Soltysik, Seumas wrote:

>I would like to propose a few changes to the current JMX functionality.
>
>Currently, to register an object as an MBean in CXF the following steps must occur (see
InstrumentationManagerTest):
>
>1)Get a handle to EventProcessor extension
>2)Create an Event wrapping the object you want to expose as an MBean
>3)Send Event to EventProcessor
>4)This event will be picked up by a Listener(InstrumentationManagerImpl), which is responsible
for passing it on to the JMXManagedComponentManager only if the manager is in fact instantiated(i.e.
the system actually has instantiated an MBeanServer).
>5)The JMXComponentManager then creates a ModelMBean based upon the annotations associated
with the original object sent as part of the original event.
>
>  
>
Yes, this event framework just let the CXF management get to know when 
and which managed componet had been created or been destoried.

>I don't see that event framework(EventProcessor, EventListener) plays an important role
in registering an MBean. I would like to see a simpler set of steps:
>
>1)Get a handle to JMXManagagedComponentManager (maybe change name to MBeanServerFacade)
directly from Bus extension map. The manager would contain config/policy info indicating whether
a user actually wants to have an MBeanServer instantiated or not. This is already being done
in the Listener(InstrumentationManagerImpl) but should be moved to the Manager(JMXManagagedComponentManager
). If the MBeanServer has not been initialized, then the calls to registerMBean() are a no-op.
>2)call Manager.registerMBean()
>
>  
>
We can get it simple in this way.
I think we can leverage AOP to provide configureable managed component 
which we can decide to call registerMBean or not when it do the post 
construction work without hard code.

>In addition, the current framework requires the following before two interfaces to be
implemented, InstrumentationFactory and Instrumentation  in order to expose an object as an
MBean(see WorkQueueManagerImpl). The InstrumentFactory interface provides for the creation
of an Instrumentation object. The EventListener registered with the EventProcessor calls createInstrumentation()
on the Factory. The Instrumention object is assumed to contain JMX annotations which are used
to create a DynamicMBean. The Instrumentation interface essentially provides a way to generate
a unique ObjectName for MBean being registered.
>
>  
>
Yep, InstrumetationFactory just make a connection between the 
instrumentation instance and managed component instance.

>Without the Event framework being part of the process of registering an Object as an MBean
the InstrumentFactory interface does not play a real role. Only the Instrumentation interface
is of value. Currently this interface looks like this: 
>
>public interface Instrumentation {
>
>    /**
>     * get the Instrumentation Name, this name is base on class 
>     * which implement instrumentation interface
>     * @return the instrumentation name      
>     */
>    String getInstrumentationName();    
>    
>    /**
>     * get the instrumentation managed component  
>     * @return the Component object reference 
>     */
>    Object getComponent();
>    
>    /**
>     * get the unique Instrumentation Name, this name is base on class instance
>     * which implement instrumentation interface
>     * @return the instrumentation name and instance number  
>     */
>    String getUniqueInstrumentationName();
>       
>}
>
>I would like to see it changed to this:
>
>public interface Instrumentation {
>
>    ObjectName getObjectName();
>       
>}
>
>With these changes, to register an Object as an MBean a user would do the following:
>
>1)Add annotations to the class that they want instrumented
>  
>
>2)Implement getObjectName() operation on class so that a unique ObjectName is returned
for each instance registered as an MBean.
>3)call registerMBean(Intrumentation) directly on JMXManagedComponentManager
>
>Alternatively a user can provide their own ObjectName if they don't want to implement
the Instrumentation interface on the class that is being wrapped by the MBean. So the following
steps would suffice:
>
>1)Add annotations to the class that they want instrumented 
>2)call registerMBean(Object, ObjectName) directly on JMXManagedComponentManager
>
>Actually an even better idea would be if we could leverage the MBeanInfoAssembler classes
in Spring. This would allow a user to employ a number of different strategies for deciding
how they wanted to specify which operations in  a class are managed. If we did this the call
to register an MBean would look like this:
>
>registerMBean(Instrumentation, MBeanInfoAssembler)
>or
>registerMBean(Object, ObjectName, MBeanInfoAssembler)
>  
>
Yes, We can leverage the MBeanInfoAssembler.
If we have so close relationship with the Spring, we can remove the CXF 
annotation stuff because it is same with the Sping's annotation.
We can extend our own MBeanInfoAssembler on the base of spring's 
MBeanInfoAssembler to support the component which is not instantiated by 
Spring if we use the Sping JMX support stuff.

>
>As a test case for these changes I would like to change the way the WorkQueueManager is
registered as an MBean and I would also like to expose the start()/stop() operations of the
Server class via an MBean.
>
>Regards,
>Seumas
>
>
>
>
>
>
>  
>
Chrees,
Willem.


Mime
View raw message