Oops, my bad, didn't pay enough attention. I guess I meant your third
version then :)
assertEquals("Hello World", out.getIn().getBody());
assertEquals(null, out.getOut().getBody());
The in is preserved, the OUT is lost on it's way back to the caller.
Sorry,
Hadrian
On Jul 10, 2009, at 9:43 AM, Claus Ibsen wrote:
On Fri, Jul 10, 2009 at 3:27 PM, Hadrian Zbarcea<hzbar...@gmail.com>
wrote:
Hi,
My view of this is that InOnly does not mean that throughout
processing you
only have an IN in the exchange, but from a consumer perspective it
does not
need to spit out an OUT. That is you can have OUTs during
processing, and
the last one at the end will be just dropped.
Your second piece of code looks correct to me and
I would *not* store the result in an IN ever, always OUT.
I assume you mean this as first and second code?
First:
assertEquals("Hello World", out.getIn().getBody());
assertEquals("Bye World", out.getOut().getBody());
Second:
assertEquals("Bye World", out.getIn().getBody());
assertEquals(null, out.getOut().getBody());
Then the second do not comply with what you said. "I would *not*
store the result in an IN ever, always OUT."
The second code stores the result in IN at the client side.
My $0.02
Hadrian
On Jul 10, 2009, at 1:05 AM, Claus Ibsen wrote:
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.
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
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
