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. 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
