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 Fri, 01 Feb 2008 18:46:08 GMT
This totally makes sense, especially given the fact that many  
components don't make that distinction.

I created camel-316


On Feb 1, 2008, at 1:15 PM, Hiram Chirino wrote:

> I personally would like to get rid of the Fault message.  It should be
> possible ti interpret the output message as a Fault or interpret  an
> Exception as Fault.  Having an exception, a fault, and an output
> message be all valid outputs of a processor makes creating a DSL to
> handle all those cases MUCH more complex.
> Just my 2 cents.
> Regards,
> Hiram
> On Jan 31, 2008 1:18 PM, Roman Kalukiewicz < 
> > wrote:
>> 2008/1/31, Hadrian Zbarcea <>:
>>> Actually to Guillaume's point, I am strongly in favor of keeping the
>>> input.  And to be honest, I like the model the way it is, for many
>>> reasons.  One is that the model is very intuitive for people  
>>> familiar
>>> with certain standards, myself included, and the emtpy chairs don't
>>> bother me.  If I understand correctly you are not claiming that  
>>> there
>>> are features that the current model (vs yours) cannot support, just
>>> that your proposal will make it clearer.
>> That is right. I believe that current model could be harder to
>> implement all different scenarios, that we don't have to think about
>> in mine, but everything could be done in the current one (with 3
>> messages available you can for sure implement everything that can be
>> done with 1, right? ;) ). I even believe that I was able to show,  
>> that
>> my solution also can handle all features we need.
>>> Well, de gustibus non est disputandum.  If you really feel strongly
>>> about that, a vote is the way to settle it :).
>> This is what I say from the very beginning. I was simply curious if  
>> my
>> impressions are common. But the fact is, that if I want camel to
>> change in this direction, I need creators of camel to be convinced to
>> this direction and I cannot do it alone (or I have to think about my
>> own one-message-branch ;) ). It looks that you are not really
>> convinced  ;)
>> Anyway thank you for all your feedback
>> Roman
> -- 
> Regards,
> Hiram
> Blog:
> Open Source SOA

View raw message