On Sun, Mar 22, 2009 at 16:05, Ruwan Linton <[email protected]> wrote: > 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.
Any suggestion for the naming of this mediator and the syntax? > 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). Note that some time ago, it has been proposed [1] to split the <property> mediator into <setProperty> and <removeProperty>... [1] http://markmail.org/thread/3sefs5mgkrwwqfao > 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 >
