Andreas, Seems interesting and I think we should keep these functionalities into one single mediator and differentiate the behavior by an attribute. This is how we have done the transaction mediator (create new transaction, commit transaction, use existing transaction), cache mediator (cache collector, cache serve), throttle (throttling, throttle data collector) and so on.
So with this we keep the relevant (rather related) functionality into one mediator (even if we take property mediator there were no two mediators called <setProperty> and <removeProperty> which will be handled by an attribute). Thanks, Ruwan On Sat, Mar 21, 2009 at 5:17 PM, Andreas Veithen <[email protected]>wrote: > All, > > Recently there have been discussions (see e.g. SYNAPSE-503) about how > to store parts of a message for later use during a mediation. For the > moment this is possible, but requires an XML <-> string conversion. > The best solution would obviously be to allow storing elements (or > other nodes) in Synapse properties. This is allowed by the core > (property values are Objects, not strings), but currently not > supported by the <property> mediator. > > In terms of storing nodes in Synapse properties we should support the > following features: > > (1) Remove a node from the message and store it in a property. > (2) Clone a node and store the copy in a property. > > Note that I intentionally left out storing a reference to a node, > because this might have unexpected effects. I think that the node > stored in a property should not have any reference to the message > itself. > > We should also have mediators that allow to insert a stored node into > the message, i.e. support the following features: > > (3) Insert a node stored in a property into the message, either as a > child or sibling (before/after) of an existing node. > (4) Replace an existing node by a node stored in a property. > > In both cases, the user should have the possibility to choose if he > wants to insert a clone of the node or the node itself (in which case > the property should be cleared to avoid unexpected effects). > > I recently added two mediators to synapse-experimental implementing > features (1) and (4). They work well, but they will need some rework > before moving to the built-in mediators. I would like to have your > opinion on the following points: > > - Is the list of suggested features complete or are there any use > cases not covered? > - Should we implement features (1) and (2) as distinct mediators or > would it make more sense to enhance the existing <property> mediator? > - Should we have a separate mediator for each feature (e.g. > <removeNode>, <cloneNode>, <insertNode> and <replaceNode>) or should > we try to group these features into a smaller set of mediators (using > attributes to choose between remove/clone and insert/replace)? > - Suggestions for the names of these mediators. > > Regards, > > Andreas > -- Ruwan Linton Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: [email protected]; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
