2009/7/10 Claus Ibsen <claus.ib...@gmail.com>:
> Now that we have opened the box with IN OUT FAULT api changes I would
> like to point out issues related to OUT
>
> Given this code:
>
> Exchange out = template.send("direct:start", new Processor() {
> public void process(Exchange exchange) throws Exception {
> exchange.getIn().setBody("Hello World");
> exchange.setPattern(ExchangePattern.InOnly);
> }
> });
>
> And this route:
>
> from("direct:start").transform(constant("Bye World"));
>
> What would the expected output of Exchange be?
>
> The current code asserts this:
>
> assertEquals("Hello World", out.getIn().getBody());
> assertEquals("Bye World", out.getOut().getBody());
>
> That looks fair. The route transforms (= set an OUT body) and we
> preserve the original IN.
> But the exchange pattern was InOnly but we get data in OUT also? Camel
> does not adhere strictly to the patterns.
This is another point I would like to see changed - exchange patterns.
My personal impression is that exchange shouldn't have pattern at all.
When I create a flow I (usually) know at design time if I want given
endpoint to operate as InOnly or InOut. I really cannot imagine a
situation, when I design a flow and I don't really know if it should
operate in InOnly or in InOut mode, especially that sometimes it
changes a lot in the behavior of the flow.
I would like to see it as an endpoint property rather than exchange
property especially, that in majority of endpoints the pattern is
ignored anyway.
My proposal: Remove MEP concept at all from Camel API. Leave it for
specific components.
My impression is that there are more common things that could be
included into API than MEP, like timeout concept. I don't propose
timeout on API level, but definitely it is more useful and common than
MEP.
Then (if we agree that OUT is needed) everything creates OUT always -
this way we are consistent and no guesses are needed. Moreover if we
agree that everything creates OUT then everything can operate on IN
the same way. What you can always do in your code is
Object in = exchange.getMessage().getBody();
exchange.getMessage().setBody(out);
This way IF YOU NEED, you can have your IN message in the code, but it
doesn't spoil an API. It guarantees header propagation by default. No
more questions if something is in IN or OUT. Moreover IN/OUT from
user's point of view doesn't exist - pipeline hides this distinction
almost completely, because whatever you use, you will have IN in a
next step anyway.
Roman
> Now what if the route only changes the IN message (setBody only changes IN)
>
> from("direct:start").setBody(constant("Bye World"));
>
> What should the expected outcome be?
>
> Should it be as before?
>
> assertEquals("Hello World", out.getIn().getBody());
> assertEquals("Bye World", out.getOut().getBody());
>
> Or as this:
>
> assertEquals("Bye World", out.getIn().getBody());
> assertEquals(null, out.getOut().getBody());
>
>
> Its actually now that easy to get a closure on this one. Either we should
> - always store "result" in OUT and copy back the original input to IN
> - OR try to adhere the exchange pattern, and store "result" in either
> IN or OUT depending on the pattern.
>
> This is often only a matter when you send an Exchange to Camel. If you
> use the sendBody then Camel will extract
> the correct result and thus its not a problem here.
>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
