cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: JMX Changes
Date Fri, 09 Feb 2007 16:24:46 GMT
I think it was so we didn't have a dependency on Spring. I don't know at
what level that is true though - does it introduce a dependency in the sense
you have to use Spring to JMX or in the sense that you have to always have
Spring with CXF? From my POV, if this introduces the later I'd be against
solely using the Spring annotations. Otherwise I'm OK with switching over to
them.

- Dan

On 2/8/07, Soltysik, Seumas <Seumas.Soltysik@iona.com> 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:Ning.Jiang@iona.com]
> Sent: Sunday, February 04, 2007 3:08 AM
> To: cxf-dev@incubator.apache.org
> 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:eoghan.glynn@iona.com]
> Sent: 2/3/2007 1:14
> To: cxf-dev@incubator.apache.org
> 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:Seumas.Soltysik@iona.com]
> > Sent: 02 February 2007 16:27
> > To: cxf-dev@incubator.apache.org
> > 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:eoghan.glynn@iona.com]
> > Sent: Friday, February 02, 2007 6:37 AM
> > To: cxf-dev@incubator.apache.org
> > 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: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
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message