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
