I suggested the common configuration mainly due a requirement for implementing some ideas I had many time earlier. It is in archive [1] and it contains a PDF attachment describing the basic idea. Actually, a university student did a successful POC of the idea. Furthermore, In the synapse code base, I have created a package ‘aspects’ for this and added ‘AspectConfiguration’. I also used a separate interface ‘StatisticsConfigurable’ for the statistics and expected to provide interfaces for others such as tracing. However, I had no time those days, so I added some temporary code just to preserve the backward compatibility of the statistics collecting.
My preferences for a proper implementation Defining configuration A language construct that may be similar to what I have suggested in an earlier post – aspect configuration. Statistics, monitoring, etc are configured though a policy whose syntax is written in a unique way (at least like a spring bean). The global aspect configuration is named as ‘system’. It is the default one for any one. This can be overridden by defining inline aspects configurations within endpoint, sequence, etc… In addition, if it is needed to share a same configuration by many, then the configuration is defined as a named aspect configuration and each component (sequence, etc...) required it refers using an attribute ‘aspectRef’. Implementation EDA model – That can be used by any other places such as passive logging, passive persistence, etc…,. This model should support required extensibility to support SEDA model. Concepts of patterns such as Command, Event Channel, Pipe and Filters, Reactor, etc definitely help for a proper implementation. I have a little bit personal experience of the use of this kind of model. Thanks Indika [1] http://markmail.org/message/rrpalubz2dj2ff3g Please Note : These are just my preferences
