2009/7/14 Willem Jiang <willem.ji...@gmail.com>: > James Strachan wrote: >> >> 2009/7/13 Claus Ibsen <claus.ib...@gmail.com>: >>>> >>>> Reading between the lines; are you really just trying to make folks >>>> use (what is currently called) "getOut()" and never try mutate what is >>>> currently called getIn()? >>>> >>>> i.e. so by default the "OUT" property is defaulted to a copy of IN >>>> that folks can change/mutate. >>>> >>>> (what we call these 2 methods is a separate discussion, whether its >>>> "in,out" or "originalMessage,message" or whatever >>>> >>> Hadrian and I had a chat today and we are clearing up some bits. >>> I am more on line with him now on the IN and OUT thing. >>> >>> So lets keep them. >>> >>> And use the time to fix the tiny bits such as the getOut() doing its >>> lazy creating a new empty message. >>> And whether its possible to let IN be immutable. >> >> I think we're kinda mostly on the same page (though saying it in >> different ways). BTW I'm taking off my devils advocate hat now :)... >> >> What we're agreeing on I think is that; >> >> * getIn() should be immutable (when folks try to change it we can >> throw the exception and describe how getOut() should be used to change >> the message) - to prevent folks using the old code (which will require >> code changes). >> * having the original immutable message available is handy; but mostly >> folks should concentrate on the 'out' (current name today) >> * the out should be automatically populated with a clone of the IN (to >> avoid all that pain with checking if there's an out or an in, or the >> possible loss of headers etc. Internally we can use a CopyOnWrite >> facade to reduce the cost of potentially copying a message which is >> not actually mutated. >> >> Given that; I think we're mostly agreeing. However given the confusion >> of getIn() and getOut() I'm wondering if actually your previous idea >> of changing the api of exchange to have a getMessage() which returns >> the thing a processor should be changing; then having a >> getOriginalMessage() (which can be null if you are the first in the >> chain) might reduce the amount of confusion? >> >> i.e. after sleeping on it, I'm warming to the idea of renaming getIn() >> -> getOriginalMessage() and getOut() -> getMessage(). (Or maybe >> getInputMessage() for getIn()?) >> >> Thoughts? >> > +1 for this change. > > For the InOnly Message Exchange Pattern, when we want to change the message > , we just call the exchange's getMessage() and don't not care about if it's > a in message or an out message. > > For the ProduceTemplate sendMessage() method we can get the response message > back from the exchange, by using exchange.getMessage() method.
Good point. When sending a message, the getOriginalMessage() will be null (we should document that its an optional property that might be null etc). -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
