On Mon, Mar 23, 2009 at 01:01, Ruwan Linton <[email protected]> wrote: > 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?
I can agree with clone by default, but not with always clone. One use case of these mediators is to store part of a message, invoke some other service and then retrieve the stored element to use it in a subsequent request or in the response. In this case cloning the node causes unnecessary overhead. Of course if we don't clone, we should clear the property. PS: We should also have "addChild" as a possible action. > > 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 >
