2008/1/30, Hadrian Zbarcea <[EMAIL PROTECTED]>: > 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 ;) Roman
