cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: JMX Changes
Date Fri, 02 Feb 2007 11:36:56 GMT

Here's a thought on getting rid of Instrumentation.getComponent().

Suppose we want to write a JMX NotificationListener that applies some
dynamic adaption of the instrumented object's behaviour.

For example reacting to the rate of incoming spuriously resent messages
reported via an WS-RM Mbean to increase the ACK frequency.

Then it would be handy to have a reference to the "parent object"
associated with the MBean, in this case I guess the RMDestination.

This could be achieved by specifying Instrumentation.getComponent() as
the handback object param to addNotificationListener().

Now of course you could probably navigate back to the parent object in
other ways, but it could be convenient to have a standard way of doing
it.

Cheers,
Eoghan
 

> -----Original Message-----
> From: Soltysik, Seumas [mailto:Seumas.Soltysik@iona.com] 
> Sent: 02 February 2007 01:17
> To: cxf-dev@incubator.apache.org
> Subject: JMX Changes
> 
> 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.
> 
> 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()
> 
> 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.
> 
> 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)
> 
> 
> 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
> 
> 
> 
> 
> 
> 

Mime
View raw message