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