Hi Seumas, Yes, the CXF JMX Management annotations is same with the Spring JMX Management annotations 2.0M2. I will do a double check about the latest Spring Code. If so , you can modify the code to use the Spring JMX Management annotation.
Willem. Soltysik, Seumas wrote: >I see that CXF has defined its own JMX Management annotations, >ManagedResource, ManagedAttribute, etc. Is there any reason CXF is not using >the JMX annotations defined by the Spring framework? >If not then I will modify the code to use the Spring JMX Management >annotations. > > >-----Original Message----- >From: Jiang, Ning [mailto:[EMAIL PROTECTED] >Sent: Sunday, February 04, 2007 3:08 AM >To: [email protected] >Subject: RE:JMX Changes > > > >Hi Eoghan, > >The original thought to introduce the instrumentation to CXF management was we >did not want our rt code be polluted by MBean or JMX API. Instrumentation >interface's impl should be the wrapper class. The method "Object >getComponent();" was for the combination of the wrapper class and real rt >component. But now CXF's management only support JMX , so the instrumentation >and InstrumentationManager could be over design. > >We can make our management more simple and more close to JMX by getting ride >of these usefulness APIs. > >Current CXF management provides a dynamical way which can expose the >annotation class instance to JMX as Mbean. We can define which methods or >attributes should be exposed to JMX by adding different annotations. So you >still can get the control of stopping to expose the low-level API to JMX. > >For the NotificationListener implementing, I think it is easy to get the >"parent object" in the same JVM. But If the listener implementing is coming >from the management console with the different JVM , it is really hard to get >real "parent object", even we provide the getComponet() operation. >So we need to export all management options as MBean's methods to JMX for >NotificationListener implementing to use. > >Any other thoughts? > >Cheers, > >Willem. > >-----Original Message----- >From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] >Sent: 2/3/2007 1:14 >To: [email protected] >Subject: RE: JMX Changes > > >Sure we could do it that way, but it may end up exposing more low-level >detail than necessary in the MBean. > >Also there may be other reasons why it would be unsuitable for the >RMDestination itself to be the Mbean, as opposed to some decoupled >object. For example it could be easiler to persist or replicate the >RMDestination if its decoupled from the MBean infrastructure. > >So it could be more convenient if the NotificationListener implementing >the adaptive behaviour weren't restricted to what's exposed MBean, but >instead had direct acess to the "parent object". > >Cheers, >Eoghan > > > >>-----Original Message----- >>From: Soltysik, Seumas [mailto:[EMAIL PROTECTED] >>Sent: 02 February 2007 16:27 >>To: [email protected] >>Subject: RE: JMX Changes >> >>Hi Eoghan, >>Shouldn't the changes you talk about occur via the MBean >>interface of the RMDestination? When the Notification is sent >>to the listener it will pass on a reference to the >>RMDestination MBean. At this point the Listener is free to >>modify the RMDestination object via the MBean interface. This >>may not be quite as good as having access to the >>RMDestination object itself but it seems to handle the case >>you described below. >>Regards, >>Seumas >> >>-----Original Message----- >>From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] >>Sent: Friday, February 02, 2007 6:37 AM >>To: [email protected] >>Subject: RE: JMX Changes >> >> >> >>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:[EMAIL PROTECTED] >>>Sent: 02 February 2007 01:17 >>>To: [email protected] >>>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 >>> >>> >>> >>> >>> >>> >>> >>> > > > >
