camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: [DISCUSS] Semantics of IN and OUT (was: Faults and Exceptions in Camel)
Date Tue, 14 Jul 2009 13:40:36 GMT
Awesome.  This is very similar to what we agreed upon yesterday with  

I personally much prefer the in/out terminology as it has pretty  
clearly defined meaning in a few specs.
The 'original' term is a bit confusing and I would avoid it.  It could  
mean either that the original coming into the consumer, or original  
coming into a processor, and I think we mean the latter.  I am not  
totally opposed to changing the method names, but this seems to me  
just a renaming and since it would incur extra work for the users, I'd  
rather keep it as is.

With cleaning up the implementation and the documentation, which could  
be done now or post 2.0, I am pretty happy.


On Jul 14, 2009, at 5:06 AM, James Strachan wrote:

> 2009/7/14 Claus Ibsen <>:
>>> 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?
>> Very good thoughts James. I think all this will removes many  
>> obstacles
>> and confusing for new users to Camel.
>> Now even the AggregationStrategy is less tricky to use as you will
>> know that using getMessage gets what you are looking for.
>> Maybe we should create a wiki page at Camel where we can outline the
>> API proposal and ideas for the message facade.
> Yeah.
> BTW we could leave getIn() and getOut() & try implement the
> ImmutableWrapper and CopyOnWriteFacade for In/Out respectively and try
> them out inside the current API - before we go ahead with any kind of
> renaming of getIn() and getOut().
> Maybe we could even keep getIn() / getOut() around for 2.0 (and zap in
> 2.1) and leave deprecated and make them just delegate to the new
> method names (say getInputMessage() and getMessage()). The deprecated
> message could then describe how folks typically should switch
> getIn()/getOut() to using getMessage() unless they really really want
> the immutable input message getInputMessage().
> -- 
> James
> -------
> Open Source Integration

View raw message