Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <7b774c950702091141i23261b51w902f31e0c2c7887@mail.gmail.com>
Date: Fri, 9 Feb 2007 14:41:53 -0500
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: JMX Changes
In-Reply-To: <05F5FDC16A447442B12B21A432878AC5051896@amer-ems1.IONAGLOBAL.COM>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_37105_33265719.1171050113410"
References: <05F5FDC16A447442B12B21A432878AC5051896@amer-ems1.IONAGLOBAL.COM>

------=_Part_37105_33265719.1171050113410
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

If we're going to start putting these attributes on our own classes in such
a way that Spring is required to run, then I think we should continue to
have our own attributes to remove the dependency on Spring. It shouldn't be
too hard to build our own version of the annotation ModelMBeanAssembler,
right? It sounds like that is the only use case we need to worry about that
might involve a hard dependency on Spring.

- Dan

On 2/9/07, Soltysik, Seumas <Seumas.Soltysik@iona.com> wrote:
>
> Currently in CXF there is a ModelMBeanAssembler class which uses CXF
> annotations to create an MBean. Since Spring already has this type of
> functionality, it seemed to make sense to leverage what is already written.
> In addition, since Spring has a number of other MBeanAssembler classes, it
> seemed to make sense to use these as a way of making the process of
> registering MBeans more flexible. For instance there is an
> InterfaceMBeanAssembler which will assemble an MBean base upon a set of
> interfaces passed to the assembler.
> However, if CXF must be able to run without Spring, this is a problem. If
> there are internal classes that use Spring annotations, then these will not
> load if Spring is not present which is a problem.
>
> I would like to see CXF developers and CXF users be able to register their
> MBeans in a variety of ways.
> 1)Using annotations on thier classes
> 2)By specifying interfaces they would like exposed via JMX
> 3)Doing nothing at all simply expecting all public methods and date
> members to be exposed as an MBean
> 4)Using the "normal" MBean registration mechanism that depends on
> interface naming conventions[FooMBean].
>
> Perhaps the solution is to write additional assemblers which mimic the
> behavior of the Spring assemblers.
>
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Friday, February 09, 2007 11:25 AM
> To: cxf-dev@incubator.apache.org
> Subject: Re: JMX Changes
>
>
> 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
>


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

------=_Part_37105_33265719.1171050113410--