camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: in/out/fault messages discussion
Date Fri, 01 Feb 2008 18:15:04 GMT
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.


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



Open Source SOA

View raw message