camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [DISCUSS] Faults and Exceptions in Camel
Date Fri, 10 Jul 2009 13:00:00 GMT
2009/7/10 Roman Kalukiewicz <>:
> 2009/7/10 Claus Ibsen <>:
>> 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.

So what about consuming a JMS message which could be an InOnly or
InOut based on the presence of a JMSReplyTo header?

Or invoking a (say) JMS endpoint from application code using either
InOnly or InOut where the client decides based (say) an @InOnly
annotation on a Java method when doing Spring Remoting or a different
method on the ProducerTemplate in application code?

The endpoint cannot always decide by itself the MEP; sometimes the
client or the message it receives can decide it. So I think the MEP
needs to be associated with the Exchange.

> 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.

Timeouts are really useful for InOuts! Something we might want to add
- or at least have standard header/properties on the exchange?

> 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.

Not sure how you'd access the in and out together after the out had
been modified in some way?

Open Source Integration

View raw message