I would vote for both, on global and on those child elements where it is 
applicable with the simple rule, that at runtime the most specific one wins.

This would allow for the following scenarios.

Turn it off for all (globally)
Turn it off globally, but only activate it on demand for specific endpoints, 
services etc.
Turn it on globally
Turn it on globally, but disable it for some specific services, endpoints 
(exclusions)

Of cause you could also add a configuration right in the middle on the level of 
the services or endpoints etc., if someone also wants to turn an aspect only on 
for ALL services, but not for all endpoints, but just some of them.

Regards,
  Eric



________________________________
From: Supun Kamburugamuva [mailto:supu...@gmail.com]
Sent: Friday, December 04, 2009 8:15 PM
To: dev@synapse.apache.org
Subject: Re: JMX notifications for Endpoint state changes

+1 from me as well to the new aspect configuration. This solves the problem 
more cleanly.

I'm not clear about one thing. Shall we make this aspect configuration to be a 
child of other elements like mediators and endpoints or is it a top level 
configuration only?

Thanks,
Supun..
On Fri, Dec 4, 2009 at 2:23 PM, Ruwan Linton 
<ruwan.lin...@gmail.com<mailto:ruwan.lin...@gmail.com>> wrote:
+1, we should go for this, and I think it will be very useful in a production 
set up; if anything goes wrong and the admin wants to enable tracing for the 
full synapse config he do not have to go onto each and every config bit. OTOH, 
if he knows where the issue is he can just enable tracing of that proxy only.

Thnaks,
Ruwan

On Fri, Dec 4, 2009 at 2:14 PM, Hubert, Eric 
<eric.hub...@foxmobile.com<mailto:eric.hub...@foxmobile.com>> wrote:
Well, actually I thought in the same direction as Ruwan. If introducing a 
global configuration option it should be consistent with the other 
configurations like tracing and statistics. This was one point against adding 
this only for any newly introduced feature like JMX notifications. If we would 
like to use such a configuration option, than we should consistently support 
this also for statistics and tracing.

________________________________
Hi Ruwan,

I think if we do this the correct way, the way you've suggested is the correct 
way. I was bit reluctant to do that because it is kind of like a big change. At 
least at the conceptual level.

I like your idea and I'll come up with an implementation.

Eric, What do you think?


--
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com<mailto:ru...@wso2.com>; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com



--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com<http://supunk.blogspot.com>

Reply via email to