Yes! That @Namespaces annotation is a much nicer way.

   ...ant

On Dec 13, 2007 4:10 PM, Paul Fremantle <pzfreo@gmail.com> wrote:

Ant

Can I propose the following syntax as slightly neater:

@Namespaces({ "prefix:http://blah", "anotherprefix:http://"}) - an array of strings - each string is "prefix:uri"
CLASS, FIELD, METHOD

@ReadFromMessage("/xpath/")

FIELD AND METHOD - METHOD must be a setter

@UpdateMessage("/xpath");
FIELD AND METHOD - METHOD must be a getter

@ReadAndUpdate("/xpath");
Only applies to a field

Paul

On Dec 3, 2007 1:10 PM, ant elder < ant.elder@gmail.com> wrote:
I've just committed a start of this, might be better to be in a scratch area to start with but it was easier this way, can maybe move it out later. The annotations are in org.apache.synapse.mediators.annotations and theres and AnnotatedCommandMediator, and a testcase in org.apache.synapse.mediators.ext, which has  class AnnotatedCommand2 which shows this being used. So far only supports reading string values from the MessageContext but thats enough to help refine things.

I couldn't see a way to support any number of arbitrary namespace prefixes easily, so right now  you can use @Namespace with a  single arbitrary namespace prefix or with "ns", "ns1", "ns2"..."ns5". Thats on both the class and field/method so that enables defining two arbitrary namespace prefixes and if you need more than that you have to use the ns or ns1 to ns5 prefixes.  Maybe someone can think of a better way of doing this?

You have to define the soap enveloper and header or body tags in the xpath witch doesn't seem great. Maybe it would be better to have something like separate annotations for the headers and body.

I'm also wondering again if it may be simpler to have a single annotation instead of the ReadFromMessage/ReadAndUpdate/UpdateMessage ones, and have the method being a getter/setter determine if its read or update and fields always do read and update.

Anyway open to review, what to people think?

   ...ant


On Nov 20, 2007 12:38 PM, Paul Fremantle < pzfreo@gmail.com> wrote:
Aha

That is quite cunning. So in other words, if you annotate the field then we assume to get it before execute and set it after.

If you annotate the getter then we only get, annotate the setter we only set.

I like the model, but I'd like to make the annotations match the action.

So:
@namespace(ns="http://fremantle.org);
@ReadFromMessage(xpath="/ns:quote/Symbol")
public void setSymbol(String symbol) {

...

}

@UpdateMessage(xpath="/")
public OMElement getPayload() {
   // return an OMElement
}

@ReadAndUpdate(xpath="blah")
String symbol = null;

// expecting getters and setters:
String getSymbol() { }
void setSymbol(String s) { }

Does that make sense?

Since XPaths can logically refer to Strings, Booleans and Integers as well as XML, I suggest we support those as property types in the class too.

Paul



On Nov 20, 2007 12:30 PM, ant elder <antelder@apache.org > wrote:
I'm not sure it needs a getter/setter generated or the type attribute specified on the property annottaion.  The @property annotation could be used on either a field or getter/setter method:

   @property(name="symbol")
   String value

or

   @property(name="symbol")
   public void setValue(String s) {
      value = s;
   }

or

   @property(name="symbol")
   public String getValue() {
      return value;
   }

The annotation is associated with the field or method so the type can easily be introspected from that.

Also, when the annotation is associated with a method you can see if its a getter or a setter so the action can be determined from the method name (get=out, set=in).

   ...ant


On Nov 20, 2007 11:52 AM, Paul Fremantle <pzfreo@gmail.com > wrote:
Sorry that wasn't very clear was it!

Basically, I thought one approach would be to add a name and type parameter to the
@property tag

@property(name="symbol", type="String|OMElement",....)

and then (I'm assuming - based on my limited knowledge of annotations) we could automatically generate getters and setters.

The problem with this approach is that the getters/setters would not be available for command completion in the IDE, so I ditched this idea.

Paul


On Nov 20, 2007 11:47 AM, ant elder <ant.elder@gmail.com > wrote:


On Nov 20, 2007 11:44 AM, Paul Fremantle <pzfreo@gmail.com> wrote:

<snip>


- the action could really be optional as its not so hard for the runtime to see that the value has been changed and set/getandset would just be a performance optimisation
I guess so. It depends on whether we generate the property and getters/setters or not. I was kind of assuming that we wouldn't generate them. Alternatively we could cache values before and after the execute method, but thats a bit yucky, I think its so simple to use an annotation, and also since you get command completion for annotations inside IDEs we can make it a required property.
 

What do you mean by "generate the property and getters/setters"?

   ...ant



--
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




--
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




--
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



--
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