camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roman Kalukiewicz" <>
Subject Re: in/out/fault messages discussion
Date Thu, 31 Jan 2008 10:05:49 GMT
2008/1/30, Hadrian Zbarcea <>:
> Hi Roman,
> But it already is like that, sort of.  If you like, imagine that your
> message has a tag (out/fault) that tells us how that message got
> there, that we also keep the previous message around (in).

This is exactly what I'm trying to propose.
The difference is like between one chair and possible labels on it, or
three chairs labeled in constant way. When I have one chair, I know
where to sit. When I have three, I don't. Moreover consequences of
this choice are significant, and not always clear. (OK - I know that
software is not a furniture ;) )

Whole discussion here is maybe simply about some taste - I prefer my
the model I shown, while you prefer current one. I can perfectly work
(and works) with the current one, and Camel is a great framework
anyway - no question about it.

I simply believe that my model is simpler and easier to understand for
our users AND it could be simpler to code (once again - maybe a matter
of taste).

What is definitely against my idea is the fact that we have already
working different model, and someone could argue "don't fix it if it
is not broken". That is true, and we have to think about backward
compatibility and other important stuff. My propose looks like a
revolution in the whole framework. I believe, that it is not a
revolution, because even now almost no component uses faults, while
in/out distinction is simply lost when you use pipeline. Moreover my
patch shows, that it is not revolution. I was able to have 1 message
in the exchange, and every test passes. It means, that we can
deprecate some methods (like getOut() and getFault()) temporarily and
we ARE backward compatible, and no more guessing if I should use in or
out message.

Just to clarify - I had to create quite complicated flow using camel
that included jms, xslts, JBI, http, splitters, error handling and
many other stuff. My proposal comes from many problems I had with
those in/out/fault messages. Many times it was a matter of guess (or
looking into the code) why something doesn't work when I set in or out
(don't mention about faults that couldn't be handled in DSL at all),
why my headers are lost, ...

All those problems could be fixed somehow - true. I'm trying to say -
don't build bridges over those rivers. Just take another route, that
doesn't have rivers at all, if it leads to the same destination...
maybe even faster ;)


View raw message