cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Soltysik, Seumas" <Seumas.Solty...@iona.com>
Subject RE: Review of patch for CXF-427 [JMX]
Date Tue, 27 Feb 2007 06:14:19 GMT
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
>>
>> 
>>
>>    
>>
>
>
>  
>


Mime
View raw message