You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@synapse.apache.org by Andreas Veithen <an...@gmail.com> on 2009/03/21 12:47:22 UTC
Storing elements in Synapse properties
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
Re: Storing elements in Synapse properties
Posted by Ruwan Linton <ru...@gmail.com>.
On Mon, Mar 30, 2009 at 7:04 AM, Asankha C. Perera <as...@apache.org>wrote:
>
> <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.
>>
>>
> Ok.. I agree with this too :-)
+1
Ruwan
>
>
> cheers
> asankha
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
>
>
>
--
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: Storing elements in Synapse properties
Posted by "Asankha C. Perera" <as...@apache.org>.
>> <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.
>
Ok.. I agree with this too :-)
cheers
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
Re: Storing elements in Synapse properties
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, Mar 23, 2009 at 01:01, Ruwan Linton <ru...@gmail.com> 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
> <an...@gmail.com>wrote:
>
>> On Sun, Mar 22, 2009 at 16:05, Ruwan Linton <ru...@gmail.com>
>> 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
>> > <an...@gmail.com>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: ruwan@wso2.com; 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: ruwan@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>
RE: Storing elements in Synapse properties
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
> > What about
> > <property name="string" (value="literal" | expression="xpath")
> > [action=set|remove|cloneAsNode|detachAsNode] [scope=...]/>
>
> My feeling is that integrating this into the property mediator will
> make it too overloaded. We would almost need to include a decision
> table into the documentation in order to explain to the user which
> combinations of attributes and attribute values are allowed :-) We
> should also make sure that we have the option (later) to provide an
> XML schema for our configuration language and this schema should
> provide a decent level of validation which is not possible with this
> degree of overloading.
While I was reading the suggestion for the first time, I definitely shared the same concern - both from a user's as well as from a developer's perspective. Anyway I wanted to sleep a bit over it and wait for other reactions. Well, the sleep did not change anything and I'm still thinking this would become unnecessary complex.
> I would definitely prefer a distinct mediator (maybe <extract>?)
> implementing clone and detach, as well as the remove operation
> suggested below.
+1
Regards,
Eric
Re: Storing elements in Synapse properties
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, Mar 23, 2009 at 09:08, Asankha C. Perera <as...@apache.org> 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.
>>
>
> What about
> <property name="string" (value="literal" | expression="xpath")
> [action=set|remove|cloneAsNode|detachAsNode] [scope=...]/>
My feeling is that integrating this into the property mediator will
make it too overloaded. We would almost need to include a decision
table into the documentation in order to explain to the user which
combinations of attributes and attribute values are allowed :-) We
should also make sure that we have the option (later) to provide an
XML schema for our configuration language and this schema should
provide a decent level of validation which is not possible with this
degree of overloading.
I would definitely prefer a distinct mediator (maybe <extract>?)
implementing clone and detach, as well as the remove operation
suggested below.
>>
>> 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"]/>
>>
>
> This looks good, I think we also need a slight variant mediator to just
> remove a node (i.e. without setting it as a property)
>
> cheers
> asankha
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
>
> http://esbmagic.blogspot.com
>
>
>
>
>
Re: Storing elements in Synapse properties
Posted by "Asankha C. Perera" <as...@apache.org>.
> 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.
>
What about
<property name="string" (value="literal" | expression="xpath")
[action=set|remove|cloneAsNode|detachAsNode] [scope=...]/>
> 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"]/>
>
This looks good, I think we also need a slight variant mediator to just
remove a node (i.e. without setting it as a property)
cheers
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
Re: Storing elements in Synapse properties
Posted by Ruwan Linton <ru...@gmail.com>.
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
<an...@gmail.com>wrote:
> On Sun, Mar 22, 2009 at 16:05, Ruwan Linton <ru...@gmail.com>
> 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
> > <an...@gmail.com>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: ruwan@wso2.com; 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: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: Storing elements in Synapse properties
Posted by Andreas Veithen <an...@gmail.com>.
On Sun, Mar 22, 2009 at 16:05, Ruwan Linton <ru...@gmail.com> 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
> <an...@gmail.com>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: ruwan@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>
Re: Storing elements in Synapse properties
Posted by Ruwan Linton <ru...@gmail.com>.
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
<an...@gmail.com>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: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com