Hi Paul, In order to achieve the serialization we will need to keep the setter informations with both Class and Command (Pojo). That is because, we may set only a set of attributes in those objects rather than setting all of them in the configuration; in which case we must only serialize with the properties that we have set only.
For example if we have a ClassMediator with attributes x, y and z but we set only x and y in the configuration and the CMF (ClassMediatorFactory) will pick these correctly and to serialize the exact behavior we need to know what attributes has been set and what not. So we need to keep this in a list. Apart from that if we want the expression behavior (that is to set some attributes at the runtime from the message using XPATH) we will have to iterate through the expression set and evaluate those before calling the mediate method (same with the pojo case). If a particular mediator doesn't set any expressions then the behavior is exactly same as the static property case. If this is OK to proceed, I will go ahead and implement this. Thanks, Ruwan. On 8/1/07, Paul Fremantle <[EMAIL PROTECTED]> wrote: > > Also I think its clearer. I didn't really understand the point of the > dynamic properties before (Doh!). > > It might be better to call this the <pojo> instead of <command> > because the objects really would be POJOs (i.e. they would not need to > implement any synapse-specific interface. > > For that reason I suggest we use reflection to implement this. (I > looked for a javax....Command interface but couldn't find one). That > means you can write one of these objects without needing any Synapse > JARs in your build path which I think is a good thing. > > Paul > > On 8/1/07, Asankha C. Perera <[EMAIL PROTECTED]> wrote: > > Paul > > > > Yep.. this is certainly good! It would leave the best of both worlds > > > > asankha > > > > Paul Fremantle wrote: > > > I changed the class mediator to only use static properties so that > > > they would be set before the class.init() was called. > > > > > > However, Asankha has pointed out to me that there is another model > > > that the dynamic properties had, which is to use XPath properties to > > > set data on the mediator before it is called, thereby meaning that > > > there is no need for user to need to understand OMElement or > > > MessageContext to write a mediator. > > > > > > I guess I see these as two completely separate ways to write a > > > mediator. In fact I see three potential approaches: > > > > > > 1) mediate(MessageContext mc) > > > 2) set/get XPath data in/out of the message > > > 3) Use ADB or Databinding and write Java based on the message type > > > > > > I'm not sure about the third option - it not very "loosely-coupled" > > > but I can see how it would appeal to Java developers. I'd be happy to > > > leave that till later. > > > > > > However, I think 1 and 2 are really distinct cases. > > > > > > The second model is really something called the Command Pattern. You > > > can read about it here: > > > http://en.wikipedia.org/wiki/Command_pattern > > > http://www.javaworld.com/javaworld/javatips/jw-javatip68.html?page=1 > > > > > > Basically this model is where you call: > > > > > > obj.setX(y); > > > obj.setQ(z); > > > obj.setF(e); > > > obj.execute(); > > > obj.getX() > > > obj.getQ() > > > obj.getF(); > > > > > > It seems like we could define a nice model for this in Synapse: > > > <command class="org.fremantle.Command"> <!-- class must implement > > > "void execute();" --> > > > <property name="Name" expression="xpath expression" > > > action="set|get|setAndGet" type="String|float|double|boolean|..."/> > > > <property name="Symbol" expression="//Symbol" action="get" > type="String"/> > > > <property name="Symbol" expression="/getQuoteResponse/Price[0]" > > > action="set" type="Double"/> > > > </command> > > > > > > Basically what this will do is allow the user to write a real POJO > > > that implements getters and setters as well as the execute(); method. > > > We then call XPaths and set data into the object, then call execute(); > > > then we update the message based on data from the getters. > > > > > > Thoughts? > > > > > > Paul > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Paul Fremantle > Co-Founder and VP of Technical Sales, WSO2 > OASIS WS-RX TC Co-chair > > blog: http://pzf.fremantle.org > [EMAIL PROTECTED] > > "Oxygenating the Web Service Platform", www.wso2.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ruwan Linton http://www.wso2.org - "Oxygenating the Web Services Platform"
