You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Ruwan Linton <ru...@apache.org> on 2007/12/12 07:10:53 UTC
POJOCommand mediator synatx
Hi devs,
Now POJOCommand mediator supports both set properties to the object and
getting them from the object to the message back with using the action
attribute. Paul and I had a chat about this syntax and though of using
somewhat similar to the notations of the AnnotatedCommand mediator, so the
new effective configuration is going to be like following;
<pojoCommand name="class-name">
<property name="string" value="literal">
either literal or XML child
</property>
<property name="string" context-name="string" action=("UpdateContext" |
"ReadContext" | "ReadAndUpdateContext")>
<property name="string" expression="XPATH expression"
action=("ReadMessage" | "UpdateMessage" | "ReadAndUpdateMessage")/>
</pojoCommand>
For the name value pair properties and name and xml child properties there
is no action because it is always going to be Read to the Command object but
not going to be Updates.
Do we need to support mix of these actions as well? For example if one needs
to read the command property as a name value pair and update the message
with that property as a message property as illustrated bellow;
set xyz="ruwan"
execute
get xyz => //request/person/name
if we form a single action for this it is going to be
["ReadValueAndUpdateMessage"]
WDYT?
Thanks,
Ruwan
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
Re: POJOCommand mediator synatx
Posted by "Asankha C. Perera" <as...@wso2.com>.
Paul
I now see a potential problem with this.. what if someone specified a
fn:concat() expression as the XPath expression, and wanted that to be
set to the POJO? According to your suggestion we will not be able to
intelligently decide in such a case..
asankha
Paul Fremantle wrote:
> Ruwam
>
> What I don't like about this is that everywhere else in Synapse we
> have a consistent access to message context properties. Nowhere else
> do we use this syntax.
>
> Whatever we do we need to sync it up with all the other places where
> we get and set mc properties I think - e.g. DBLookup, etc.
>
> Paul
>
> On Dec 14, 2007 3:42 AM, Ruwan Linton <ruwan.linton@gmail.com
> <ma...@gmail.com>> wrote:
>
> Pual,
>
> Well. I think it's a hack and a bit tricky.
>
> I have simplified the configuration a little bit to remove the mix
> case as it is obvious that is one is *Read* then the other should
> be *Update*.
>
> But I prefer to keep the context-name attribute with those actions
> due to two reasons.
>
> 1) the configuration is clean and does not have any hidden meaning
> (for example; it does not contain if the action is Update then the
> get-property refers to set-property)
> 2) using the get-property to retrieve message context properties
> is a round trip in execution, (we can by pass that using a string
> comparison as you suggested in the Update case, but I don't feel
> like it is right .. :() obviously even with this configuration
> user has the ability to specify the get as a get-property but at
> the same time he has the simple faster config as well.
>
> Following is the simplified configuration that I have already
> implemented.
>
> <pojoCommand name="class-name">
> <property name="string" value="literal"/> <!-- refers to action
> ==> ReadValue -->
> <property name="string" expression="/xpath/expression"
> action=("ReadMessage" | "UpdateMessage" | "ReadAndUpdateMessage")/>
> <property name="string" value="literal"
> expression="/xpath/expression"/> <!-- refers to action
> ==>ReadValueAndUpdateMessage -->
> <property name="string" context-name="string"
> action=("ReadContext" | "UpdateContext" | "ReadAndUpdateContext")/>
> <property name="string" value="literal" context-name="string"/>
> <!-- refers to action ==>ReadValueAndUpdateContext -->
> <property name="string" context-name="string"
> expression="/xpath/expression" action=("ReadMessage" |
> "ReadContext")/> <!-- if read one then update the other -->
> </pojoCommand>
>
> Thanks,
> Ruwan
>
>
> On Dec 13, 2007 9:17 PM, Paul Fremantle < pzfreo@gmail.com
> <ma...@gmail.com>> wrote:
>
> Ruwan
>
> I propose one modification. I'd really like to get rid of the
> whole Context stuff. It should be automatic.
> Here is my proposal.
>
> 1) We figure out if we can make the
> get-property('context-name') also allow updating the message
> context too.
> 2) We just see if the XPath is a 'get-property'. When we come
> to update the message, if its a get-property we bypass
> Jaxen/XPath and directly update the context.
>
> That way the syntax can just be:
>
> <pojoCommand name="class-name">
> <property name="string" value="literal"/>
> <property name="string" expression="/xpath/expression or
> get-property('context-property')" action=("ReadMessage" |
> "UpdateMessage" | "ReadAndUpdateMessage")/>
> </pojoCommand>
>
> Thoughts?
>
> Paul
>
>
>
> On Dec 12, 2007 6:10 AM, Ruwan Linton < ruwan@apache.org
> <ma...@apache.org>> wrote:
>
> Hi devs,
>
> Now POJOCommand mediator supports both set properties to
> the object and getting them from the object to the message
> back with using the action attribute. Paul and I had a
> chat about this syntax and though of using somewhat
> similar to the notations of the AnnotatedCommand mediator,
> so the new effective configuration is going to be like
> following;
>
> <pojoCommand name="class-name">
> <property name="string" value="literal">
> either literal or XML child
> </property>
> <property name="string" context-name="string"
> action=("UpdateContext" | "ReadContext" |
> "ReadAndUpdateContext")>
> <property name="string" expression="XPATH expression"
> action=("ReadMessage" | "UpdateMessage" |
> "ReadAndUpdateMessage")/>
> </pojoCommand>
>
> For the name value pair properties and name and xml child
> properties there is no action because it is always going
> to be Read to the Command object but not going to be Updates.
>
> Do we need to support mix of these actions as well? For
> example if one needs to read the command property as a
> name value pair and update the message with that property
> as a message property as illustrated bellow;
>
> set xyz="ruwan"
> execute
> get xyz => //request/person/name
>
> if we form a single action for this it is going to be
> ["ReadValueAndUpdateMessage"]
>
> WDYT?
>
> Thanks,
> Ruwan
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
>
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com <ma...@wso2.com>
>
> "Oxygenating the Web Service Platform", www.wso2.com
> <http://www.wso2.com>
>
>
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
>
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org <http://pzf.fremantle.org>
> paul@wso2.com <ma...@wso2.com>
>
> "Oxygenating the Web Service Platform", www.wso2.com
> <http://www.wso2.com>
Re: POJOCommand mediator synatx
Posted by Ruwan Linton <ru...@gmail.com>.
Hi ant,
Sorry for the late.
Here is the scenario that illustrates the point that we are discussing.
We need to set the field named "test" of the TestCommand class with the
value "testvalue" before execution and set the field value to the message
context property with the name "testcontext" after the execution.
Here is what my proposed configuration for the above scenario (actually the
current code supports this :) )
<POJOCommand class="org.apache.synapse.TestCommand">
<property name="test" value="test value" context-name="testcontext"/>
</POJOCommand>
And here is what paul like it to be,
<POJOCommand class="org.apache.synapse.TestCommand">
<property name="test" value="test value"
expression="get-property('testcontext')"/>
</POJOCommand>
Paul wants the configuration to be simple (don't want to add another
attribute context-name and use the expression attribute), but I think this
configuration is confusing because it has the get-property to actually mean
a set property. This is the problem.
(Note: I have avoided the actions since it will make this more complex, but
when we add context-name there will be three more actions namely
"ReadContext", "UpdateContext", "ReadAndUpdateContext")
Paul, please correct me if I have interpreted your views wrongly.
Thanks,
Ruwan
On Dec 14, 2007 4:30 PM, ant elder <an...@gmail.com> wrote:
> Could someone post actual examples of the simplest xml with each approach
> so we can see the differences?
>
> ...ant
>
>
> On Dec 14, 2007 10:08 AM, Ruwan Linton < ruwan.linton@gmail.com> wrote:
>
> > Paul,
> >
> > On Dec 14, 2007 1:52 PM, Paul Fremantle < pzfreo@gmail.com> wrote:
> >
> > > Ruwam
> >
> >
> > I think you are referring to me (Ruwan) not some one named Ruwam :)
> >
> > Well, even though we need to keep the consistency, at the same time we
> > have to keep the things simpler to understand and the implementation solid.
> > But I don't see this as simple to understand.
> >
> > To me this syntax is cleaner than what you suggested.
> >
> > Thanks,
> > Ruwan
> >
> >
> > >
> > > What I don't like about this is that everywhere else in Synapse we
> > > have a consistent access to message context properties. Nowhere else do we
> > > use this syntax.
> > >
> > > Whatever we do we need to sync it up with all the other places where
> > > we get and set mc properties I think - e.g. DBLookup, etc.
> > >
> > > Paul
> >
> >
> >
> >
> > --
> > Ruwan Linton
> > http://www.wso2.org - "Oxygenating the Web Services Platform"
> >
>
>
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
Re: POJOCommand mediator synatx
Posted by ant elder <an...@gmail.com>.
Could someone post actual examples of the simplest xml with each approach so
we can see the differences?
...ant
On Dec 14, 2007 10:08 AM, Ruwan Linton <ru...@gmail.com> wrote:
> Paul,
>
> On Dec 14, 2007 1:52 PM, Paul Fremantle <pz...@gmail.com> wrote:
>
> > Ruwam
>
>
> I think you are referring to me (Ruwan) not some one named Ruwam :)
>
> Well, even though we need to keep the consistency, at the same time we
> have to keep the things simpler to understand and the implementation solid.
> But I don't see this as simple to understand.
>
> To me this syntax is cleaner than what you suggested.
>
> Thanks,
> Ruwan
>
>
> >
> > What I don't like about this is that everywhere else in Synapse we have
> > a consistent access to message context properties. Nowhere else do we use
> > this syntax.
> >
> > Whatever we do we need to sync it up with all the other places where we
> > get and set mc properties I think - e.g. DBLookup, etc.
> >
> > Paul
>
>
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
Re: POJOCommand mediator synatx
Posted by Ruwan Linton <ru...@gmail.com>.
Paul,
On Dec 14, 2007 1:52 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Ruwam
I think you are referring to me (Ruwan) not some one named Ruwam :)
Well, even though we need to keep the consistency, at the same time we have
to keep the things simpler to understand and the implementation solid. But I
don't see this as simple to understand.
To me this syntax is cleaner than what you suggested.
Thanks,
Ruwan
>
> What I don't like about this is that everywhere else in Synapse we have a
> consistent access to message context properties. Nowhere else do we use this
> syntax.
>
> Whatever we do we need to sync it up with all the other places where we
> get and set mc properties I think - e.g. DBLookup, etc.
>
> Paul
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
Re: POJOCommand mediator synatx
Posted by Paul Fremantle <pz...@gmail.com>.
Ruwam
What I don't like about this is that everywhere else in Synapse we have a
consistent access to message context properties. Nowhere else do we use this
syntax.
Whatever we do we need to sync it up with all the other places where we get
and set mc properties I think - e.g. DBLookup, etc.
Paul
On Dec 14, 2007 3:42 AM, Ruwan Linton <ru...@gmail.com> wrote:
> Pual,
>
> Well. I think it's a hack and a bit tricky.
>
> I have simplified the configuration a little bit to remove the mix case as
> it is obvious that is one is *Read* then the other should be *Update*.
>
> But I prefer to keep the context-name attribute with those actions due to
> two reasons.
>
> 1) the configuration is clean and does not have any hidden meaning (for
> example; it does not contain if the action is Update then the get-property
> refers to set-property)
> 2) using the get-property to retrieve message context properties is a
> round trip in execution, (we can by pass that using a string comparison as
> you suggested in the Update case, but I don't feel like it is right .. :()
> obviously even with this configuration user has the ability to specify the
> get as a get-property but at the same time he has the simple faster config
> as well.
>
> Following is the simplified configuration that I have already implemented.
>
> <pojoCommand name="class-name">
> <property name="string" value="literal"/> <!-- refers to action ==>
> ReadValue -->
> <property name="string" expression="/xpath/expression"
> action=("ReadMessage" | "UpdateMessage" | "ReadAndUpdateMessage")/>
> <property name="string" value="literal" expression="/xpath/expression"/>
> <!-- refers to action ==>ReadValueAndUpdateMessage -->
> <property name="string" context-name="string" action=("ReadContext" |
> "UpdateContext" | "ReadAndUpdateContext")/>
> <property name="string" value="literal" context-name="string"/> <!--
> refers to action ==>ReadValueAndUpdateContext -->
> <property name="string" context-name="string"
> expression="/xpath/expression" action=("ReadMessage" | "ReadContext")/> <!--
> if read one then update the other -->
> </pojoCommand>
> Thanks,
> Ruwan
>
>
> On Dec 13, 2007 9:17 PM, Paul Fremantle < pzfreo@gmail.com> wrote:
>
> > Ruwan
> >
> > I propose one modification. I'd really like to get rid of the whole
> > Context stuff. It should be automatic.
> > Here is my proposal.
> >
> > 1) We figure out if we can make the get-property('context-name') also
> > allow updating the message context too.
> > 2) We just see if the XPath is a 'get-property'. When we come to update
> > the message, if its a get-property we bypass Jaxen/XPath and directly update
> > the context.
> >
> > That way the syntax can just be:
> >
> > <pojoCommand name="class-name">
> > <property name="string" value="literal"/>
> > <property name="string" expression="/xpath/expression or
> > get-property('context-property')" action=("ReadMessage" | "UpdateMessage" |
> > "ReadAndUpdateMessage")/>
> > </pojoCommand>
> >
> > Thoughts?
> >
> > Paul
> >
> >
> >
> > On Dec 12, 2007 6:10 AM, Ruwan Linton < ruwan@apache.org> wrote:
> >
> > > Hi devs,
> > >
> > > Now POJOCommand mediator supports both set properties to the object
> > > and getting them from the object to the message back with using the action
> > > attribute. Paul and I had a chat about this syntax and though of using
> > > somewhat similar to the notations of the AnnotatedCommand mediator, so the
> > > new effective configuration is going to be like following;
> > >
> > > <pojoCommand name="class-name">
> > > <property name="string" value="literal">
> > > either literal or XML child
> > > </property>
> > > <property name="string" context-name="string"
> > > action=("UpdateContext" | "ReadContext" | "ReadAndUpdateContext")>
> > > <property name="string" expression="XPATH expression"
> > > action=("ReadMessage" | "UpdateMessage" | "ReadAndUpdateMessage")/>
> > > </pojoCommand>
> > >
> > > For the name value pair properties and name and xml child properties
> > > there is no action because it is always going to be Read to the Command
> > > object but not going to be Updates.
> > >
> > > Do we need to support mix of these actions as well? For example if one
> > > needs to read the command property as a name value pair and update the
> > > message with that property as a message property as illustrated bellow;
> > >
> > > set xyz="ruwan"
> > > execute
> > > get xyz => //request/person/name
> > >
> > > if we form a single action for this it is going to be
> > > ["ReadValueAndUpdateMessage"]
> > >
> > > WDYT?
> > >
> > > Thanks,
> > > Ruwan
> > >
> > > --
> > > Ruwan Linton
> > > http://www.wso2.org - "Oxygenating the Web Services Platform"
> >
> >
> >
> >
> > --
> > Paul Fremantle
> > Co-Founder and VP of Technical Sales, WSO2
> > OASIS WS-RX TC Co-chair
> >
> > blog: http://pzf.fremantle.org
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
>
>
>
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: POJOCommand mediator synatx
Posted by Ruwan Linton <ru...@gmail.com>.
Pual,
Well. I think it's a hack and a bit tricky.
I have simplified the configuration a little bit to remove the mix case as
it is obvious that is one is *Read* then the other should be *Update*.
But I prefer to keep the context-name attribute with those actions due to
two reasons.
1) the configuration is clean and does not have any hidden meaning (for
example; it does not contain if the action is Update then the get-property
refers to set-property)
2) using the get-property to retrieve message context properties is a round
trip in execution, (we can by pass that using a string comparison as you
suggested in the Update case, but I don't feel like it is right .. :()
obviously even with this configuration user has the ability to specify the
get as a get-property but at the same time he has the simple faster config
as well.
Following is the simplified configuration that I have already implemented.
<pojoCommand name="class-name">
<property name="string" value="literal"/> <!-- refers to action ==>
ReadValue -->
<property name="string" expression="/xpath/expression"
action=("ReadMessage" | "UpdateMessage" | "ReadAndUpdateMessage")/>
<property name="string" value="literal" expression="/xpath/expression"/> <!--
refers to action ==>ReadValueAndUpdateMessage -->
<property name="string" context-name="string" action=("ReadContext" |
"UpdateContext" | "ReadAndUpdateContext")/>
<property name="string" value="literal" context-name="string"/> <!--
refers to action ==>ReadValueAndUpdateContext -->
<property name="string" context-name="string"
expression="/xpath/expression" action=("ReadMessage" | "ReadContext")/> <!--
if read one then update the other -->
</pojoCommand>
Thanks,
Ruwan
On Dec 13, 2007 9:17 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Ruwan
>
> I propose one modification. I'd really like to get rid of the whole
> Context stuff. It should be automatic.
> Here is my proposal.
>
> 1) We figure out if we can make the get-property('context-name') also
> allow updating the message context too.
> 2) We just see if the XPath is a 'get-property'. When we come to update
> the message, if its a get-property we bypass Jaxen/XPath and directly update
> the context.
>
> That way the syntax can just be:
>
> <pojoCommand name="class-name">
> <property name="string" value="literal"/>
> <property name="string" expression="/xpath/expression or
> get-property('context-property')" action=("ReadMessage" | "UpdateMessage" |
> "ReadAndUpdateMessage")/>
> </pojoCommand>
>
> Thoughts?
>
> Paul
>
>
>
> On Dec 12, 2007 6:10 AM, Ruwan Linton < ruwan@apache.org> wrote:
>
> > Hi devs,
> >
> > Now POJOCommand mediator supports both set properties to the object and
> > getting them from the object to the message back with using the action
> > attribute. Paul and I had a chat about this syntax and though of using
> > somewhat similar to the notations of the AnnotatedCommand mediator, so the
> > new effective configuration is going to be like following;
> >
> > <pojoCommand name="class-name">
> > <property name="string" value="literal">
> > either literal or XML child
> > </property>
> > <property name="string" context-name="string" action=("UpdateContext"
> > | "ReadContext" | "ReadAndUpdateContext")>
> > <property name="string" expression="XPATH expression"
> > action=("ReadMessage" | "UpdateMessage" | "ReadAndUpdateMessage")/>
> > </pojoCommand>
> >
> > For the name value pair properties and name and xml child properties
> > there is no action because it is always going to be Read to the Command
> > object but not going to be Updates.
> >
> > Do we need to support mix of these actions as well? For example if one
> > needs to read the command property as a name value pair and update the
> > message with that property as a message property as illustrated bellow;
> >
> > set xyz="ruwan"
> > execute
> > get xyz => //request/person/name
> >
> > if we form a single action for this it is going to be
> > ["ReadValueAndUpdateMessage"]
> >
> > WDYT?
> >
> > Thanks,
> > Ruwan
> >
> > --
> > Ruwan Linton
> > http://www.wso2.org - "Oxygenating the Web Services Platform"
>
>
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
Re: POJOCommand mediator synatx
Posted by Paul Fremantle <pz...@gmail.com>.
Ruwan
I propose one modification. I'd really like to get rid of the whole Context
stuff. It should be automatic.
Here is my proposal.
1) We figure out if we can make the get-property('context-name') also allow
updating the message context too.
2) We just see if the XPath is a 'get-property'. When we come to update the
message, if its a get-property we bypass Jaxen/XPath and directly update the
context.
That way the syntax can just be:
<pojoCommand name="class-name">
<property name="string" value="literal"/>
<property name="string" expression="/xpath/expression or
get-property('context-property')" action=("ReadMessage" | "UpdateMessage" |
"ReadAndUpdateMessage")/>
</pojoCommand>
Thoughts?
Paul
On Dec 12, 2007 6:10 AM, Ruwan Linton <ru...@apache.org> wrote:
> Hi devs,
>
> Now POJOCommand mediator supports both set properties to the object and
> getting them from the object to the message back with using the action
> attribute. Paul and I had a chat about this syntax and though of using
> somewhat similar to the notations of the AnnotatedCommand mediator, so the
> new effective configuration is going to be like following;
>
> <pojoCommand name="class-name">
> <property name="string" value="literal">
> either literal or XML child
> </property>
> <property name="string" context-name="string" action=("UpdateContext" |
> "ReadContext" | "ReadAndUpdateContext")>
> <property name="string" expression="XPATH expression"
> action=("ReadMessage" | "UpdateMessage" | "ReadAndUpdateMessage")/>
> </pojoCommand>
>
> For the name value pair properties and name and xml child properties there
> is no action because it is always going to be Read to the Command object but
> not going to be Updates.
>
> Do we need to support mix of these actions as well? For example if one
> needs to read the command property as a name value pair and update the
> message with that property as a message property as illustrated bellow;
>
> set xyz="ruwan"
> execute
> get xyz => //request/person/name
>
> if we form a single action for this it is going to be
> ["ReadValueAndUpdateMessage"]
>
> WDYT?
>
> Thanks,
> Ruwan
>
> --
> Ruwan Linton
> http://www.wso2.org - "Oxygenating the Web Services Platform"
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com