Thanks James :),
-1 from on the same counts
Hadrian
On Jul 10, 2009, at 9:00 AM, James Strachan wrote:
2009/7/10 Roman Kalukiewicz <roman.kalukiew...@gmail.com>:
2009/7/10 Claus Ibsen <claus.ib...@gmail.com>:
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
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
