On Sun, Dec 6, 2009 at 11:35 PM, Hubert, Eric <eric.hub...@foxmobile.com>wrote:
> Please see my comments inline! > > > > 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. > > Ah, OK – now I understand what you meant. > > > 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. > > > > Yes, this is an option although I don’t think it would be the only option. > Another option would be to allow the aspects block on any level: global > (under definitions), global for all services or sequences or endpoints > (wherever it makes sense) and on each individual service, or sequence or > endpoint. The global default could be overridden wherever you like. So for > your example globally everything is turned off, but only on the sequences > level the tracing is activated. This means it is only active for all > sequences, until you decide to exclude some sequences explicitly on the > particular sequence. > > > > Maybe you option is easier to understand, but not that flexible and > definitely not the only option. If you would like to trace all but 10 out of > 100 sequences, you would need to activate it on 90 sequences. With the above > approach you would activate it at the global sequence level and only > deactivate it on those 10 sequences you want to exclude. > Eric, the issue in the synapse configuration language is that you do not have a section which declares the sequences to do this, sequences, endpoints, proxies and all local entries are on the same XML depth and there is no chance to specify this configuraiton as you explained. If we had a <sequences> tag enclosing all the sequence definitions, this would have been the ideal approach, but it is not the case :-( Thanks, Ruwan > > > 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. :-) > > +1 > -- 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
