camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: [DISCUSS] Faults and Exceptions in Camel
Date Fri, 10 Jul 2009 13:34:54 GMT
Thanks James :),

-1 from on the same counts

On Jul 10, 2009, at 9:00 AM, James Strachan wrote:

> 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?
> -- 
> James
> -------
> Open Source Integration

View raw message