camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: in/out/fault messages discussion
Date Wed, 30 Jan 2008 16:49:16 GMT
Aaron, thanks for your input!  Comments inline.


On Jan 30, 2008, at 10:55 AM, Aaron Crickenberger wrote:

> On Jan 30, 2008, at 5:21 AM, Roman Kalukiewicz wrote:
>> WSDL describes formats of in/out/fault messages, because they are
>> different (formats).
>>> Inputs are sort of read-only from the point of view of the next
>>> processor in the pipeline.
>> That is not definitely true, as in majority of cases we agree to
>> modify in message, and propagate it. BTW it is very handy as if you
>> want your headers to be propagated you simply cannot fill out message
>> in DSL.
>> This way it is YOU who define when you want your flow to be
>> interrupted. I can imagine that we can treat like a fault the fact
>> that your mail endpoint received a mail with 'no such address'  
>> string.
>> By belief is that such approach is simpler and more universal than
>> what we currently have. It is also how I can imagine some fault
>> handling in camel (that simply doesn't exist so far).
> Allow me to comment as a bit of an outsider here, as I haven't been  
> too involved with the parts of Camel that actually use the out/fault  
> messages, nor the exception handling capabilities.
> As I understand it the whole reason Exchange exists is to model the  
> correlation between the in/out/fault messages, not their format.   
> Maybe the abstraction is too leaky to hide, but I thought that's  
> what Camel was trying to do.  If you remove the distinction from  
> Camel's API, it then becomes the responsibility of the players  
> involved in the to keep track of the correlation.  That, to me  
> anyway, sounds like it makes life more difficult for users of Camel,  
> or at the least, anyone implementing a Camel component.
> As Hadrian said, I think a number of your concerns can be address by  
> revisiting Pipeline and a few of the core routing mechanisms.  The  
> in/out/fault distinction may not be clear or consistent throughout  
> Camel, and rmaking it so is not a simple task,
I don't think it's a major effort either.  For the most part Camel  
*does* things right.

> but I think to get rid of it entirely is throwing out the baby with  
> the bathwater, so to speak.

> For example, as you point out, the in/out distinction is clunky to  
> processors that only want to modify a message or pass it along.  The  
> convention or shortcut that's come about for these cases is merely  
> modifying/using the In message, and having Pipeline forward it  
> along.  Perhaps some benefit could come from further utilizing  
> ExchangePattern, or generating better default wrappers from the DSL.
> - aaron

View raw message