I suggest we use the property mediator itself for [1] and [2] as follows; <property name="string" [action=set|remove] (value="literal" | expression="xpath") (node="clone" | "detach") [scope=transport|axis2|axis2-client]/>
where, the introduced attribute node declares that it is a node operation and this option is valid only when the action is "set" and the expression attribute is present. So the clone attribute value clones the node and attach it as a node to the specified property name and the detach value will remove the node form the message and attach as a property. With this we preserve the earlier behavior of the property mediator, if you do not specify the node attribute it will be the string value of the expression that we are going to be storing in the property. For [3] and [4] I suggest we go for a single mediator called enrich with the following syntax. <enrich name="string" expression="xpath" action=["insertBefore" | "insertAfter" | "replace"]/> The name attribute is the property name to be extracted, and the expression is the xpath describing the attach node specified by the attaching action which can be one of the above three options. I suggest we always clone the node before enriching the message with that property node. WDYT? Thanks, Ruwan On Mon, Mar 23, 2009 at 2:56 AM, Andreas Veithen <[email protected]>wrote: > 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 > > > -- 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
