Hi, > Do we need configuration changes for this? We can set these properties > using property mediator and then introduces some layer (before sending > message) that do work based on these special properties- special > property handlers. I'm not sure whether the generic approach will always be the best. Increasing the number of properties set in the message context increases also the complexity. Aren't properties in the message context only important if we need them at several different places within the message flow (e.g. at one point in the flow they are set and at totally different location they are read?). I'm not quite sure about this as I'm still in the process to familiarize with Synapse. In our case now, we are talking about properties which apply exactly for one mediator, or? So why using a generic approach, if a direct configuration of a specific mediator would be straight and easy to understand?
> Then, we can avoid any configuration changes. Hmm. This point I don't get. Do you mean avoid any change of a specific mediator factory? Or do you refer to the compatibility of existing configurations? I think the latter would not be a problem as we are talking about the addition of an optional property. > be an abstraction that does decoration around sending. I didn’t look > at possibility of doing this. But, I feel it is doable and it > introduce some extensibility. Even for Hessian case, we may able to > use a special property handler. I know you are quite busy, but if have the time could you please detail you thoughts about a possible usage of this concept for the Hessian protocol. The "problem" with the Hessian case is, that a decision has to be done at runtime. Most likely not only Hessian messages may pass a specific sequence, but at least the http transport has to behave differently. So this is quite hard to handle via a static configuration option. Anyway users are always happy for any configuration line to save. Regards, Eric
