On Fri, Jul 10, 2009 at 3:50 PM, Hadrian Zbarcea<hzbar...@gmail.com> wrote:
> 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.
And its lost because the exchange pattern was set to InOnly?
>
> 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
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
