One final thing, maybe we should call this PojoCommand - since its both a Pojo and a Command?
Paul On 8/6/07, Paul Fremantle <[EMAIL PROTECTED]> wrote: > Asankha > > The POJO mediator MUST be instantiated new for each message. Otherwise > you need to implement some reset() pattern, and I think that makes it > too complex. Therefore, the model is slightly different to how you > describe. > > CLASS: > When Synapse calls ClassMediator.init(): > ClassMediator calls > * m.setX(), > * m.setY(), > * optionally init(SynEnv); > > When Synapse calls ClassMediator.mediate() > * ClassMediator calls m.mediate(); > > POJO > When Synapse calls PojoMediator.init() > * PojoMediator can lookup and store Method fields to make invocation > more efficient. > [Suppose we define properties X in, Y inout, Z out] > Synapse calls PojoMediator.mediate(): > pojoMediator calls: > * Mediator.class.newInstance() > * p.setX(), > * p.setY(), > * [optionally init(SynapseEnv)] > * p.execute(), > * p.getY(), > * p.getZ(), > * [optionally destroy()] > > Paul > > On 8/6/07, Asankha C. Perera <[EMAIL PROTECTED]> wrote: > > > > Ruwan > > > > Basically this means that the ClassMediator and PojoMediator have almost > > the same semantics. i.e. all static name/value properties are set on init() > > by the factory, and all dynamic attributes set before each invocation of the > > mediate() or the POJO execute method (this name should be configurable via > > an attribute on the Pojo mediator) > > > > Im +1 for this.. the factories and serializers would handle the persistence > > appropriately > > > > asankha > > > > > > Ruwan Linton wrote: > > 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" > > --------------------------------------------------------------------- > > 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 > -- 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]
