+1 for integrating the ideas that came up on this thread and do the implementation.
See my comments in-line as well; On Sun, Dec 6, 2009 at 5:40 PM, Hubert, Eric <eric.hub...@foxmobile.com>wrote: > Hi, > > > > I 100% agree with Ruwan, that a global configuration shall not address > individual services, endpoints or sequences. This would make the > configuration extremely hard to read and understand. I think of this more in > an object oriented fashion as properties of the elements inheriting defaults > from their parents. Anyway I think I already stated my idea. > > > > I’m not against the idea of defining named policies/aspects and reference > them on any level, but at the moment, I do not see the big value. It would > make perfectly sense, if such a configuration would consist of many sub > configuration elements we would like to share across multiple configuration > elements. For a single boolean or even a set of booleans, this might not > make it easier to understand without adding any extra value. > I agree with you, but we can keep that for future, if we are going to have complex policies as aspect configurations that you do not want to duplicate within the entries. > Anyway I can’t imagine a useful referenced bundling of individual aspects. > Maybe I got something wrong with your last idea Ruwan, but wouldn’t the user > end up with some fancy named aspect configurations like this ALL-OFF, > ALL-ON, ONLY_STATISTIC, ONLY_TRACING, ONLY_NOTIFICATION, > STATISTIC_AND_NOTIFICATION and thousands of other potentially useful > combinations just to reuse the combination of Booleans? This doesn’t sound > like being of help. > So here what I meant is not defining a set of named aspect configurations.... Rather the aspect configuration at the root level can be used to globally turn on that for all services but not endpoints, or all endpoints but not for sequences and so on. Why I think this is important is lets say you have a state in your production server where you do not exactly know which sequence is receiving the malformed messages (you do not yet know which sequence) but you do not want to clutter the trace log with all traces, and this option will allow you to turn on tracing for all the sequences without enabling tracing for other entries like endpoints and so on... If this feature was not there the only option that you had is to put the aspect configuration into each and every sequence in your configuration. I didn't think of a good configuration option for this, whether we use string literals to refer to entries or a symbolic type. Any way I am open to not to include this as well, since it is sort of a corner case. > Indika proposed a policy definitions per aspect type to externalize, if I > got it right. This would make sense for me at the moment a policy could > contain more elements than just the Boolean, e.g. a certain further > filtering – on, but only for some defined events. In order to not have to > redefine those filters all over the place, one could reference a policy > definition. Could make perfectly sense and would be very open for more > complex aspect configurations. > Lets get started with the existing boolean values and keep the space to include policies later on, because we do not have a concrete requirement to support policies right now, we might not do it correctly and it is better to address that when the need arises. :-) Thanks, Ruwan > Too me the concept of inheritance from global definitions across the > different levels would help most to reduce the configuration amount. And > this is independent from using simple attributes with on/off or complex > referenced policies. So maybe all ideas can be integrated into a good > solution? > > > > Regards, > > Eric > > > ------------------------------ > > *From:* Ruwan Linton [mailto:ruwan.lin...@gmail.com] > *Sent:* Saturday, December 05, 2009 3:44 AM > > *To:* dev@synapse.apache.org > *Subje* > *ct:* Re: JMX notifications for Endpoint state changes > > > > Hhhmmm, not sure whether it is good to keep a one global aspect > configuration which configures all the child nodes even when you need to > turn on statistics (for example) for a given sequence, that will make the > configuration readability harder. I would think of the implementation when > deciding the configuration design, so that it is not affecting the > performance as well. > > I would like to keep a global configuration of aspects, yes as Supun > explined that can define whether all services, all endpoints or > sequences.... but not a named entity. The default behaviour will be at > global level all these will be turned off for all types of entities. > > Then at each and every element level you can define there aspects using the > same configuraiton. > > Alternately, we could let the aspect configurations to be refered from from > all the elements, inorder to make this work we need to be able to define a > named set of aspects and from services and sequences they can refer to its > aspect. It will enable us to reuse the aspect configuraitons of the same > type within different elements without redefining. > > Being said all that I would like to do the initial implementation of this, > considering the amount of change that this idea is going to take us. > > Thanks, > Ruwan > > On Sat, Dec 5, 2009 at 2:04 AM, Supun Kamburugamuva <supu...@gmail.com> > wrote: > > Hi, > > If we can define the statistics enabled endpoints or mediators at the top > level aspect configuration we can leave the aspect configuration element > only to the top level. This reduce the clutter from the specific component > configurations. Specific component configurations can focus only on what > they are mean to do. Things like statistics collection can be separated from > the mediator configurations. > > Thanks, > Supun.. > > > > On Sat, Dec 5, 2009 at 1:56 AM, Hubert, Eric <eric.hub...@foxmobile.com> > wrote: > > 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> > 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> > 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; cell: +94 77 341 3097 > blog: http://ruwansblog.blogspot.com > > > > > -- > Software Engineer, WSO2 Inc > http://wso2.org > supunk.blogspot.com > > > > > -- > Software Engineer, WSO2 Inc > http://wso2.org > supunk.blogspot.com > > > > > -- > Ruwan Linton > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb > WSO2 Inc.; http://wso2.org > email: ru...@wso2.com; cell: +94 77 341 3097 > blog: http://ruwansblog.blogspot.com > -- Ruwan Linton Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
