You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Soltysik, Seumas" <Se...@iona.com> on 2007/02/16 00:32:22 UTC
Review of patch for CXF-427 [JMX]
I just uploaded a patch file for Jira CXF-427 which involves a refactoring of the current JMX infrastructure. Could someone take a look at this patch and apply it if deemed sufficient.
Thanks,
Seumas
RE: Review of patch for CXF-427 [JMX]
Posted by "Soltysik, Seumas" <Se...@iona.com>.
Hi William,
In order to handle the process of toggling performance interceptors, I would like to expose the various InterceptorProviders(Bus, Service, Endpoint) as MBeans and allow the user to add or remove interceptors from these Providers. In this way a user can choose to include performance metric interceptors at runtime or not.
As for AOP, I would suggest putting this off for a bit. Let's continue with the current approach to instrumenting runtime objects. I think that at this point it is more important to consider what we instrument and what functionality we expose as opposed to over-engineering how we instrument these objects.
Regards,
Seumas
-----Original Message-----
From: Willem Jiang [mailto:ning.jiang@iona.com]
Sent: Monday, February 26, 2007 10:57 PM
To: cxf-dev@incubator.apache.org
Subject: Re: Review of patch for CXF-427 [JMX]
Hi Seumas,
There is a use case that comes from the performance counting. You know
the counting will take some addition resource. If the user want to turn
off the counting and still want to monitor other instrumented object of
CXF. We can not meet this requirement by enabling/disabling
InstrumentationManager via configuration at startup time.
I am not an AOP expert, but I think we may define an instrumentation
Advice (just like performance counting) to some components Join point
(just like ServletController invoke method) to implement this use case.
Cheers,
Willem.
Soltysik, Seumas wrote:
>Hi Willem,
>Yes I removed the eventing mechanism for registering instrumented objects as I think it is redundant and not necessary.
>I am not sure I understand your question regarding disabling/enabling instrumented objects. Currently you can be enabled/disabled instrumentation via configuration at startup time. A user cannot selectively decide which components need managing. They either get all or none, although I am looking into adding instrumentation dynamically during runtime.
>As for the use of AOP, I am not sure that it is necessary. The amount of code required to register an instrumented object is fairly minimal at this point, so AOP may be overkill.
>Perhaps you could give more detatils regarding what you see as a better way using AOP.
>Regards,
>Seumas
>
>-----Original Message-----
>From: Willem Jiang [mailto:ning.jiang@iona.com]
>Sent: Monday, February 26, 2007 3:16 AM
>To: cxf-dev@incubator.apache.org
>Subject: Re: Review of patch for CXF-427 [JMX]
>
>
>Hi Seumas,
>
>I just came back from vacation, I am sorry for reply your mail late.
>
>I went through the patch about the JMX infrastructure. I found you
>remove the CXF event which used by InstrumentationManager for handle the
>components' creation and destruction.
>You also take the WorkQueue as an example for the instrumentation.
> Here are two questions about them.
>1. How can I configure the JMX infrastructure to enable or disable
>center kind of CXF components' instrumentation without change the CXF code ?
> My suggestion is we can use AOP to add the component register code
>dynamically, it would be easy to implement this.
>2. About the getObjectName(), if there are two WorkQueue in the same
>bus, the two WorkQueue's ObjectName will be same.
> May be we need to take some other parameter to build up the ObjectName.
>
>Cheers,
>
>Willem.
>
>Soltysik, Seumas wrote:
>
>
>
>>I just uploaded a patch file for Jira CXF-427 which involves a refactoring of the current JMX infrastructure. Could someone take a look at this patch and apply it if deemed sufficient.
>>Thanks,
>>Seumas
>>
>>
>>
>>
>>
>
>
>
>
Re: Review of patch for CXF-427 [JMX]
Posted by Willem Jiang <ni...@iona.com>.
Hi Seumas,
There is a use case that comes from the performance counting. You know
the counting will take some addition resource. If the user want to turn
off the counting and still want to monitor other instrumented object of
CXF. We can not meet this requirement by enabling/disabling
InstrumentationManager via configuration at startup time.
I am not an AOP expert, but I think we may define an instrumentation
Advice (just like performance counting) to some components Join point
(just like ServletController invoke method) to implement this use case.
Cheers,
Willem.
Soltysik, Seumas wrote:
>Hi Willem,
>Yes I removed the eventing mechanism for registering instrumented objects as I think it is redundant and not necessary.
>I am not sure I understand your question regarding disabling/enabling instrumented objects. Currently you can be enabled/disabled instrumentation via configuration at startup time. A user cannot selectively decide which components need managing. They either get all or none, although I am looking into adding instrumentation dynamically during runtime.
>As for the use of AOP, I am not sure that it is necessary. The amount of code required to register an instrumented object is fairly minimal at this point, so AOP may be overkill.
>Perhaps you could give more detatils regarding what you see as a better way using AOP.
>Regards,
>Seumas
>
>-----Original Message-----
>From: Willem Jiang [mailto:ning.jiang@iona.com]
>Sent: Monday, February 26, 2007 3:16 AM
>To: cxf-dev@incubator.apache.org
>Subject: Re: Review of patch for CXF-427 [JMX]
>
>
>Hi Seumas,
>
>I just came back from vacation, I am sorry for reply your mail late.
>
>I went through the patch about the JMX infrastructure. I found you
>remove the CXF event which used by InstrumentationManager for handle the
>components' creation and destruction.
>You also take the WorkQueue as an example for the instrumentation.
> Here are two questions about them.
>1. How can I configure the JMX infrastructure to enable or disable
>center kind of CXF components' instrumentation without change the CXF code ?
> My suggestion is we can use AOP to add the component register code
>dynamically, it would be easy to implement this.
>2. About the getObjectName(), if there are two WorkQueue in the same
>bus, the two WorkQueue's ObjectName will be same.
> May be we need to take some other parameter to build up the ObjectName.
>
>Cheers,
>
>Willem.
>
>Soltysik, Seumas wrote:
>
>
>
>>I just uploaded a patch file for Jira CXF-427 which involves a refactoring of the current JMX infrastructure. Could someone take a look at this patch and apply it if deemed sufficient.
>>Thanks,
>>Seumas
>>
>>
>>
>>
>>
>
>
>
>
RE: Dynamically deploying interceptors via JMX
Posted by "Soltysik, Seumas" <Se...@iona.com>.
What I want to do is add a wrapper around the Bus and expose this wrapper as a managed bean. The managed bean would have the addInInterceptor(Id)/addOutInterceptor(Id) methods on it and would create/fetch the inteceptor and add it to the Bus InterceptorProvider. So to be able to use the Spring BeanFactory for accessing beans this wrapper would need a handle to the ApplicationContext.
-----Original Message-----
From: Dan Diephouse [mailto:dan@envoisolutions.com]
Sent: Tuesday, February 27, 2007 10:59 AM
To: cxf-dev@incubator.apache.org
Subject: Re: Dynamically deploying interceptors via JMX
So you want the Bus to have the addInterceptor(id) method? Or would that be
the function of the instrumentationManager? It would seem rather odd to me
to have the former. If its the later, you could just make the
InstrumentationManager ApplicationContextAware, no? (of course I probably
don't understand all the ins and outs quite yet...)
- Dan
On 2/26/07, Soltysik, Seumas <Se...@iona.com> wrote:
>
> Hi Dan,
> In order to use the ApplicationContextAware mechanism, the object I am
> instrumenting would have to created by Spring itself which is not
> necessarily the case.
> Here is what I would like to do:
> 1)Expose the Bus as an MBean. In the CXFBusImpl constructor, construct an
> MBeanWrapper around the Bus and register it with the InstrumentationManager.
> This BusMBeanWrapper would have a addInterceptor(String id) method on it. It
> would be nice if this wrapper had a handle to the ApplicationContext which
> was used to create the Bus. However, since the Bus itself is not
> ApplicationContextAware, I am not sure how to do this.
> 2)Users call addInterceptor(String id) on Bus MBean. This id is used to
> lookup interceptor from ApplicationContext so that if this method is called
> several times, the same interceptor is always used for the given ID.
>
> For starters, users would have to define any interceptors that they
> expected to use in the bean.xml file used to configure the Bus. Later on
> we could make such that Interceptors beans could be specified at runtime.
> Seumas
>
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Monday, February 26, 2007 12:33 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Dynamically deploying interceptors via JMX
>
>
> In your JMX component you could implement ApplicationContextAware which
> will
> give you a handle on the ApplicationContext.
>
> What if the interceptor isn't previously defined in an XML file? For
> example, lets say I want to add a logging interceptor. I would have to
> have
> it predefined in my beans.xml then, right?
>
> - Dan
>
> On 2/26/07, Soltysik, Seumas <Se...@iona.com> wrote:
> >
> > I would like to expose the various InterceptorProviders (Bus, Service,
> > Endpoint) as MBeans and provide methods on these MBeans to dynamically
> > deploy interceptors into these providers. In order to do this, I need a
> > mechanism to instantiate an interceptor before adding it to the
> provider.
> > Now I could pass in a classname to the MBean [BusMBean.addInterceptor
> (classname)]
> > and instantiate the interceptor that way but that seems lame. A better
> way
> > would be if I could get a handle on the Spring BeanFactory used to
> create
> > other CXF objects and use it as a factory for creating dynamic
> interceptors.
> > So instead of using a classname to instantiate an object, I could simply
> use
> > a spring id to get a handle on the desired interceptor. I am think that
> a
> > user could specify their interceptor bean in the cxf*.xml file used to
> > configure the bus and later reference the bean using the id.
> > Is it possible to get a handle on the BeanFactory used to load Bus
> > configuration? Is this a reasonable approach?
> > Regards,
> > Seumas
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Dynamically deploying interceptors via JMX
Posted by Dan Diephouse <da...@envoisolutions.com>.
So you want the Bus to have the addInterceptor(id) method? Or would that be
the function of the instrumentationManager? It would seem rather odd to me
to have the former. If its the later, you could just make the
InstrumentationManager ApplicationContextAware, no? (of course I probably
don't understand all the ins and outs quite yet...)
- Dan
On 2/26/07, Soltysik, Seumas <Se...@iona.com> wrote:
>
> Hi Dan,
> In order to use the ApplicationContextAware mechanism, the object I am
> instrumenting would have to created by Spring itself which is not
> necessarily the case.
> Here is what I would like to do:
> 1)Expose the Bus as an MBean. In the CXFBusImpl constructor, construct an
> MBeanWrapper around the Bus and register it with the InstrumentationManager.
> This BusMBeanWrapper would have a addInterceptor(String id) method on it. It
> would be nice if this wrapper had a handle to the ApplicationContext which
> was used to create the Bus. However, since the Bus itself is not
> ApplicationContextAware, I am not sure how to do this.
> 2)Users call addInterceptor(String id) on Bus MBean. This id is used to
> lookup interceptor from ApplicationContext so that if this method is called
> several times, the same interceptor is always used for the given ID.
>
> For starters, users would have to define any interceptors that they
> expected to use in the bean.xml file used to configure the Bus. Later on
> we could make such that Interceptors beans could be specified at runtime.
> Seumas
>
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Monday, February 26, 2007 12:33 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Dynamically deploying interceptors via JMX
>
>
> In your JMX component you could implement ApplicationContextAware which
> will
> give you a handle on the ApplicationContext.
>
> What if the interceptor isn't previously defined in an XML file? For
> example, lets say I want to add a logging interceptor. I would have to
> have
> it predefined in my beans.xml then, right?
>
> - Dan
>
> On 2/26/07, Soltysik, Seumas <Se...@iona.com> wrote:
> >
> > I would like to expose the various InterceptorProviders (Bus, Service,
> > Endpoint) as MBeans and provide methods on these MBeans to dynamically
> > deploy interceptors into these providers. In order to do this, I need a
> > mechanism to instantiate an interceptor before adding it to the
> provider.
> > Now I could pass in a classname to the MBean [BusMBean.addInterceptor
> (classname)]
> > and instantiate the interceptor that way but that seems lame. A better
> way
> > would be if I could get a handle on the Spring BeanFactory used to
> create
> > other CXF objects and use it as a factory for creating dynamic
> interceptors.
> > So instead of using a classname to instantiate an object, I could simply
> use
> > a spring id to get a handle on the desired interceptor. I am think that
> a
> > user could specify their interceptor bean in the cxf*.xml file used to
> > configure the bus and later reference the bean using the id.
> > Is it possible to get a handle on the BeanFactory used to load Bus
> > configuration? Is this a reasonable approach?
> > Regards,
> > Seumas
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Dynamically deploying interceptors via JMX
Posted by "Soltysik, Seumas" <Se...@iona.com>.
Hi Dan,
In order to use the ApplicationContextAware mechanism, the object I am instrumenting would have to created by Spring itself which is not necessarily the case.
Here is what I would like to do:
1)Expose the Bus as an MBean. In the CXFBusImpl constructor, construct an MBeanWrapper around the Bus and register it with the InstrumentationManager. This BusMBeanWrapper would have a addInterceptor(String id) method on it. It would be nice if this wrapper had a handle to the ApplicationContext which was used to create the Bus. However, since the Bus itself is not ApplicationContextAware, I am not sure how to do this.
2)Users call addInterceptor(String id) on Bus MBean. This id is used to lookup interceptor from ApplicationContext so that if this method is called several times, the same interceptor is always used for the given ID.
For starters, users would have to define any interceptors that they expected to use in the bean.xml file used to configure the Bus. Later on we could make such that Interceptors beans could be specified at runtime.
Seumas
-----Original Message-----
From: Dan Diephouse [mailto:dan@envoisolutions.com]
Sent: Monday, February 26, 2007 12:33 PM
To: cxf-dev@incubator.apache.org
Subject: Re: Dynamically deploying interceptors via JMX
In your JMX component you could implement ApplicationContextAware which will
give you a handle on the ApplicationContext.
What if the interceptor isn't previously defined in an XML file? For
example, lets say I want to add a logging interceptor. I would have to have
it predefined in my beans.xml then, right?
- Dan
On 2/26/07, Soltysik, Seumas <Se...@iona.com> wrote:
>
> I would like to expose the various InterceptorProviders (Bus, Service,
> Endpoint) as MBeans and provide methods on these MBeans to dynamically
> deploy interceptors into these providers. In order to do this, I need a
> mechanism to instantiate an interceptor before adding it to the provider.
> Now I could pass in a classname to the MBean [BusMBean.addInterceptor(classname)]
> and instantiate the interceptor that way but that seems lame. A better way
> would be if I could get a handle on the Spring BeanFactory used to create
> other CXF objects and use it as a factory for creating dynamic interceptors.
> So instead of using a classname to instantiate an object, I could simply use
> a spring id to get a handle on the desired interceptor. I am think that a
> user could specify their interceptor bean in the cxf*.xml file used to
> configure the bus and later reference the bean using the id.
> Is it possible to get a handle on the BeanFactory used to load Bus
> configuration? Is this a reasonable approach?
> Regards,
> Seumas
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Dynamically deploying interceptors via JMX
Posted by Dan Diephouse <da...@envoisolutions.com>.
In your JMX component you could implement ApplicationContextAware which will
give you a handle on the ApplicationContext.
What if the interceptor isn't previously defined in an XML file? For
example, lets say I want to add a logging interceptor. I would have to have
it predefined in my beans.xml then, right?
- Dan
On 2/26/07, Soltysik, Seumas <Se...@iona.com> wrote:
>
> I would like to expose the various InterceptorProviders (Bus, Service,
> Endpoint) as MBeans and provide methods on these MBeans to dynamically
> deploy interceptors into these providers. In order to do this, I need a
> mechanism to instantiate an interceptor before adding it to the provider.
> Now I could pass in a classname to the MBean [BusMBean.addInterceptor(classname)]
> and instantiate the interceptor that way but that seems lame. A better way
> would be if I could get a handle on the Spring BeanFactory used to create
> other CXF objects and use it as a factory for creating dynamic interceptors.
> So instead of using a classname to instantiate an object, I could simply use
> a spring id to get a handle on the desired interceptor. I am think that a
> user could specify their interceptor bean in the cxf*.xml file used to
> configure the bus and later reference the bean using the id.
> Is it possible to get a handle on the BeanFactory used to load Bus
> configuration? Is this a reasonable approach?
> Regards,
> Seumas
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Dynamically deploying interceptors via JMX
Posted by "Soltysik, Seumas" <Se...@iona.com>.
I would like to expose the various InterceptorProviders (Bus, Service, Endpoint) as MBeans and provide methods on these MBeans to dynamically deploy interceptors into these providers. In order to do this, I need a mechanism to instantiate an interceptor before adding it to the provider. Now I could pass in a classname to the MBean [BusMBean.addInterceptor(classname)] and instantiate the interceptor that way but that seems lame. A better way would be if I could get a handle on the Spring BeanFactory used to create other CXF objects and use it as a factory for creating dynamic interceptors. So instead of using a classname to instantiate an object, I could simply use a spring id to get a handle on the desired interceptor. I am think that a user could specify their interceptor bean in the cxf*.xml file used to configure the bus and later reference the bean using the id.
Is it possible to get a handle on the BeanFactory used to load Bus configuration? Is this a reasonable approach?
Regards,
Seumas
RE: Review of patch for CXF-427 [JMX]
Posted by "Soltysik, Seumas" <Se...@iona.com>.
Hi Willem,
Yes I removed the eventing mechanism for registering instrumented objects as I think it is redundant and not necessary.
I am not sure I understand your question regarding disabling/enabling instrumented objects. Currently you can be enabled/disabled instrumentation via configuration at startup time. A user cannot selectively decide which components need managing. They either get all or none, although I am looking into adding instrumentation dynamically during runtime.
As for the use of AOP, I am not sure that it is necessary. The amount of code required to register an instrumented object is fairly minimal at this point, so AOP may be overkill.
Perhaps you could give more detatils regarding what you see as a better way using AOP.
Regards,
Seumas
-----Original Message-----
From: Willem Jiang [mailto:ning.jiang@iona.com]
Sent: Monday, February 26, 2007 3:16 AM
To: cxf-dev@incubator.apache.org
Subject: Re: Review of patch for CXF-427 [JMX]
Hi Seumas,
I just came back from vacation, I am sorry for reply your mail late.
I went through the patch about the JMX infrastructure. I found you
remove the CXF event which used by InstrumentationManager for handle the
components' creation and destruction.
You also take the WorkQueue as an example for the instrumentation.
Here are two questions about them.
1. How can I configure the JMX infrastructure to enable or disable
center kind of CXF components' instrumentation without change the CXF code ?
My suggestion is we can use AOP to add the component register code
dynamically, it would be easy to implement this.
2. About the getObjectName(), if there are two WorkQueue in the same
bus, the two WorkQueue's ObjectName will be same.
May be we need to take some other parameter to build up the ObjectName.
Cheers,
Willem.
Soltysik, Seumas wrote:
>I just uploaded a patch file for Jira CXF-427 which involves a refactoring of the current JMX infrastructure. Could someone take a look at this patch and apply it if deemed sufficient.
>Thanks,
>Seumas
>
>
>
Re: Review of patch for CXF-427 [JMX]
Posted by Willem Jiang <ni...@iona.com>.
Hi Seumas,
I just came back from vacation, I am sorry for reply your mail late.
I went through the patch about the JMX infrastructure. I found you
remove the CXF event which used by InstrumentationManager for handle the
components' creation and destruction.
You also take the WorkQueue as an example for the instrumentation.
Here are two questions about them.
1. How can I configure the JMX infrastructure to enable or disable
center kind of CXF components' instrumentation without change the CXF code ?
My suggestion is we can use AOP to add the component register code
dynamically, it would be easy to implement this.
2. About the getObjectName(), if there are two WorkQueue in the same
bus, the two WorkQueue's ObjectName will be same.
May be we need to take some other parameter to build up the ObjectName.
Cheers,
Willem.
Soltysik, Seumas wrote:
>I just uploaded a patch file for Jira CXF-427 which involves a refactoring of the current JMX infrastructure. Could someone take a look at this patch and apply it if deemed sufficient.
>Thanks,
>Seumas
>
>
>
Re: Review of patch for CXF-427 [JMX]
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
This might of interest :
http://weblogs.java.net/blog/emcmanus/archive/2006/11/jsr262_and_wsma.html
The idea behind the spec mentioned there is that a JMX WS connector will expose the JMX instrumentation details through a
WS-Management like. There's was a paper on the convergence of various management protocols like WS-management and WSDM and the JMX
WS-Connector spec takes that into consideration...
Cheers, Sergey
----- Original Message -----
From: "Liu, Jervis" <jl...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Saturday, February 17, 2007 7:43 AM
Subject: RE: Review of patch for CXF-427 [JMX]
Exactly, this is a design choice. We either need to make an abstract layer then build up everything like JMX/SNMP/WSDM etc on top
it, or we just use JMX in the core, then bridge everything else from JMX, for example JMX-SNMP etc.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 2007?2?17? 4:26
> To: cxf-dev@incubator.apache.org
> Subject: Re: Review of patch for CXF-427 [JMX]
>
>
> FWIW, I have written a JMX->SNMP plugin which is available here:
>
> http://svn.apache.org/repos/asf/geronimo/xbean/sandbox/xbean-jmx/
>
> I have not looked at WSDM yet, but it would be great to know
> whether an
> abstraction layer is really needed or whether we could just use JMX
> throughout. From an SNMP point of view, I don't think its a
> requirement that
> we have an abstraction layer though. I will be sure to read
> the relavent
> tuscany discussion though.
>
> Seumas: been meaning to look at your patch, but I haven't had
> a chance yet
> today. It is open on my desktop though :-)
>
> - Dan
>
> On 2/16/07, Liu, Jervis <jl...@iona.com> wrote:
> >
> > Hi Seumas, sorry I did not follow the previous discussion
> of "JMX Changes"
> > very closely, I should have raised this concern early. I
> believe there is
> > still one concern needs to be addressed, which was
> mentioned by Willem, but
> > has not been paid enough attention to.
> >
> > Basically, I agree it is possible to simply how CXF
> instrumentation works
> > by removing EventProcessor/EventListener, but I think we
> still need a good
> > discussion to decide whether or not we should make the core of CXF
> > instrumentation depends on JMX directly. CXF
> instrumentation was inherited
> > from Celtix, one of core concepts of Celtix instrumentation
> design is
> > "Instrumentation will have no hard dependency on any
> specific management
> > protocols, such as JMX", see [1]. To be honest, I am not
> sure if this is an
> > over design, as Celtix only has JMX supported anyway at the
> end of day, and
> > I do not see CXF has any immediate requirement to support management
> > protocols other than JMX, such as SNMP and WSDM. But this
> kind of capability
> > definitely appears interesting to me, and it is worth a
> good consideration
> > during the design, though the "common management model"
> approach proposed by
> > Celtix may not be the only way to achieve the goal. Back to
> couple months
> > ago, I was involved in a discussion in Tuscany on the topic of SCA
> > management where they have a requirement to support both
> JMX and WSDM for
> > Tuscany, see [2] [3] [4].
> >
> >
> > [1].
> https://wiki.objectweb.org/celtix/Wiki.jsp?page=ManamgentDevPlan
> >
> > [2].
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg03625.html
> >
> > [3].
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04025.html
> >
> > [4].
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04025.html
> >
> > Cheers,
> > Jervis
> >
> > > -----Original Message-----
> > > From: Soltysik, Seumas [mailto:Seumas.Soltysik@iona.com]
> > > Sent: 2007?2?16? 7:32
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Review of patch for CXF-427 [JMX]
> > >
> > >
> > > I just uploaded a patch file for Jira CXF-427 which involves
> > > a refactoring of the current JMX infrastructure. Could
> > > someone take a look at this patch and apply it if deemed
> sufficient.
> > > Thanks,
> > > Seumas
> > >
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
RE: Review of patch for CXF-427 [JMX]
Posted by "Liu, Jervis" <jl...@iona.com>.
Exactly, this is a design choice. We either need to make an abstract layer then build up everything like JMX/SNMP/WSDM etc on top it, or we just use JMX in the core, then bridge everything else from JMX, for example JMX-SNMP etc.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 2007?2?17? 4:26
> To: cxf-dev@incubator.apache.org
> Subject: Re: Review of patch for CXF-427 [JMX]
>
>
> FWIW, I have written a JMX->SNMP plugin which is available here:
>
> http://svn.apache.org/repos/asf/geronimo/xbean/sandbox/xbean-jmx/
>
> I have not looked at WSDM yet, but it would be great to know
> whether an
> abstraction layer is really needed or whether we could just use JMX
> throughout. From an SNMP point of view, I don't think its a
> requirement that
> we have an abstraction layer though. I will be sure to read
> the relavent
> tuscany discussion though.
>
> Seumas: been meaning to look at your patch, but I haven't had
> a chance yet
> today. It is open on my desktop though :-)
>
> - Dan
>
> On 2/16/07, Liu, Jervis <jl...@iona.com> wrote:
> >
> > Hi Seumas, sorry I did not follow the previous discussion
> of "JMX Changes"
> > very closely, I should have raised this concern early. I
> believe there is
> > still one concern needs to be addressed, which was
> mentioned by Willem, but
> > has not been paid enough attention to.
> >
> > Basically, I agree it is possible to simply how CXF
> instrumentation works
> > by removing EventProcessor/EventListener, but I think we
> still need a good
> > discussion to decide whether or not we should make the core of CXF
> > instrumentation depends on JMX directly. CXF
> instrumentation was inherited
> > from Celtix, one of core concepts of Celtix instrumentation
> design is
> > "Instrumentation will have no hard dependency on any
> specific management
> > protocols, such as JMX", see [1]. To be honest, I am not
> sure if this is an
> > over design, as Celtix only has JMX supported anyway at the
> end of day, and
> > I do not see CXF has any immediate requirement to support management
> > protocols other than JMX, such as SNMP and WSDM. But this
> kind of capability
> > definitely appears interesting to me, and it is worth a
> good consideration
> > during the design, though the "common management model"
> approach proposed by
> > Celtix may not be the only way to achieve the goal. Back to
> couple months
> > ago, I was involved in a discussion in Tuscany on the topic of SCA
> > management where they have a requirement to support both
> JMX and WSDM for
> > Tuscany, see [2] [3] [4].
> >
> >
> > [1].
> https://wiki.objectweb.org/celtix/Wiki.jsp?page=ManamgentDevPlan
> >
> > [2].
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg03625.html
> >
> > [3].
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04025.html
> >
> > [4].
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04025.html
> >
> > Cheers,
> > Jervis
> >
> > > -----Original Message-----
> > > From: Soltysik, Seumas [mailto:Seumas.Soltysik@iona.com]
> > > Sent: 2007?2?16? 7:32
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Review of patch for CXF-427 [JMX]
> > >
> > >
> > > I just uploaded a patch file for Jira CXF-427 which involves
> > > a refactoring of the current JMX infrastructure. Could
> > > someone take a look at this patch and apply it if deemed
> sufficient.
> > > Thanks,
> > > Seumas
> > >
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Review of patch for CXF-427 [JMX]
Posted by Dan Diephouse <da...@envoisolutions.com>.
FWIW, I have written a JMX->SNMP plugin which is available here:
http://svn.apache.org/repos/asf/geronimo/xbean/sandbox/xbean-jmx/
I have not looked at WSDM yet, but it would be great to know whether an
abstraction layer is really needed or whether we could just use JMX
throughout. From an SNMP point of view, I don't think its a requirement that
we have an abstraction layer though. I will be sure to read the relavent
tuscany discussion though.
Seumas: been meaning to look at your patch, but I haven't had a chance yet
today. It is open on my desktop though :-)
- Dan
On 2/16/07, Liu, Jervis <jl...@iona.com> wrote:
>
> Hi Seumas, sorry I did not follow the previous discussion of "JMX Changes"
> very closely, I should have raised this concern early. I believe there is
> still one concern needs to be addressed, which was mentioned by Willem, but
> has not been paid enough attention to.
>
> Basically, I agree it is possible to simply how CXF instrumentation works
> by removing EventProcessor/EventListener, but I think we still need a good
> discussion to decide whether or not we should make the core of CXF
> instrumentation depends on JMX directly. CXF instrumentation was inherited
> from Celtix, one of core concepts of Celtix instrumentation design is
> "Instrumentation will have no hard dependency on any specific management
> protocols, such as JMX", see [1]. To be honest, I am not sure if this is an
> over design, as Celtix only has JMX supported anyway at the end of day, and
> I do not see CXF has any immediate requirement to support management
> protocols other than JMX, such as SNMP and WSDM. But this kind of capability
> definitely appears interesting to me, and it is worth a good consideration
> during the design, though the "common management model" approach proposed by
> Celtix may not be the only way to achieve the goal. Back to couple months
> ago, I was involved in a discussion in Tuscany on the topic of SCA
> management where they have a requirement to support both JMX and WSDM for
> Tuscany, see [2] [3] [4].
>
>
> [1]. https://wiki.objectweb.org/celtix/Wiki.jsp?page=ManamgentDevPlan
>
> [2]. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg03625.html
>
> [3]. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04025.html
>
> [4]. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04025.html
>
> Cheers,
> Jervis
>
> > -----Original Message-----
> > From: Soltysik, Seumas [mailto:Seumas.Soltysik@iona.com]
> > Sent: 2007?2?16? 7:32
> > To: cxf-dev@incubator.apache.org
> > Subject: Review of patch for CXF-427 [JMX]
> >
> >
> > I just uploaded a patch file for Jira CXF-427 which involves
> > a refactoring of the current JMX infrastructure. Could
> > someone take a look at this patch and apply it if deemed sufficient.
> > Thanks,
> > Seumas
> >
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Review of patch for CXF-427 [JMX]
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi Seumas, sorry I did not follow the previous discussion of "JMX Changes" very closely, I should have raised this concern early. I believe there is still one concern needs to be addressed, which was mentioned by Willem, but has not been paid enough attention to.
Basically, I agree it is possible to simply how CXF instrumentation works by removing EventProcessor/EventListener, but I think we still need a good discussion to decide whether or not we should make the core of CXF instrumentation depends on JMX directly. CXF instrumentation was inherited from Celtix, one of core concepts of Celtix instrumentation design is "Instrumentation will have no hard dependency on any specific management protocols, such as JMX", see [1]. To be honest, I am not sure if this is an over design, as Celtix only has JMX supported anyway at the end of day, and I do not see CXF has any immediate requirement to support management protocols other than JMX, such as SNMP and WSDM. But this kind of capability definitely appears interesting to me, and it is worth a good consideration during the design, though the "common management model" approach proposed by Celtix may not be the only way to achieve the goal. Back to couple months ago, I was involved in a discussion in Tuscany on the topic of SCA management where they have a requirement to support both JMX and WSDM for Tuscany, see [2] [3] [4].
[1]. https://wiki.objectweb.org/celtix/Wiki.jsp?page=ManamgentDevPlan
[2]. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg03625.html
[3]. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04025.html
[4]. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04025.html
Cheers,
Jervis
> -----Original Message-----
> From: Soltysik, Seumas [mailto:Seumas.Soltysik@iona.com]
> Sent: 2007?2?16? 7:32
> To: cxf-dev@incubator.apache.org
> Subject: Review of patch for CXF-427 [JMX]
>
>
> I just uploaded a patch file for Jira CXF-427 which involves
> a refactoring of the current JMX infrastructure. Could
> someone take a look at this patch and apply it if deemed sufficient.
> Thanks,
> Seumas
>