The ExchangePattern appears to have more scope than I'd initially
believed. Just haven't had much need to delve into it that deep as most of
my use cases are for request/response we services or file unmarshaling or
even request/response with a pass of to seda or JMS and a quick response
back to the sender/requester. But if you look at the unit test I posted
earlier. It hast the following routes.
from("direct:in").to("seda:bbb").log("${exchangeId}").log("End Direct:
${body}");
from("seda:bbb").setBody(simple("bbb")).log("${exchangeId}").log("End SEDA:
${body}");
The following two test methods then invoke the direct:in with either a
sendBody (fire and forget) or requestBody (request/response). If you look
at the execution and results you'll notice that the entire global execution
order of the routes is change. With the fire and forget initial invocation
they are executed in a decoupled fashion. So the "End Direct:" shows "aaa"
while the End SEDA executes later and shows "bbb". When the request/reply
is used the whole is executed in a holistic pattern. So you end up with
"End Direct: bbb" and SEDA executes "inside" the calling route. It is
almost like you cut and past the entire SEDA route into the middle of the
direct route. It acts much more like a normal execution of a Java program
where method a calls method b calls method c. You expect the thread to run
all the way to end of method c and then return back through the call stack.
That's because the ProducerTemplate is setting the Exchange patter based
on the method you call and as you can see the effects are profound. You
can cut and past the unit test from my post above and run it and see that
difference. I also logged the exchange Ids to see what was happening when
it went from route to route. Each gets a new ID but that hasn't really
answered my question about whether it is a deep or shallow clone. Based on
behavior alone I'd say it is a shallow clone but it could also be that in
the context of a request/reply the end of the SEDA route contains an Out in
the exchange that by contract is then switched to the IN of the calling
route. But I'll have to run tests later to determine which. Ironic that
as much as I've used Camel I've never stumbled across this as fundamental
design or implementation problem. Although it is certainly possible it
would be useful in certain cases.
Claus has a bit a discussion on the point here:
http://stackoverflow.com/questions/15683944/do-we-need-inonly-annotation-or-setexchangepattern-pattern-inonly-if-we-ar
@Produce(uri = "direct:in") protected ProducerTemplate producer; @Test
public void fireAndForget() { producer.sendBody("aaa"); } @Test public void
requestReply() { String result = (String) producer.requestBody("aaa");
System.out.println("Result: "+ result); }
On Mon, Sep 26, 2016 at 8:22 AM, sim085 <sim...@hotmail.com> wrote:
> I have checked the code of PatternDefinition.inOnly(...) and this just
> calls
> the PatternDefinition.to(...) method with the ExchangePattern set to
> InOnly.
>
> So let us forget the method inOnly(). What does it mean to set the
> ExchangePattern to "InOnly" (or even "InOut")?
>
> There are various ways how this can be done; .setExchangePattern(),
> .to(ExchangePattern e), .inOnly(...), inOut(...), etc.
>
> Is the ExchangePattern parameter just a flag which the called endpoint can
> ignore?
>
> For example the following code
>
> [code]
> from("jetty:http://localhost:8282/";)
> .inOnly("direct:BBB")
> .process(new Processor(){
> public void process(Exchange e){
> System.out.println("AAA: Exchange
> Pattern is: " + e.getPattern());
> }
> });
>
> from("direct:BBB")
> .process(new Processor(){
> public void process(Exchange e){
> System.out.println("BBB: Exchange Pattern
> is: " + e.getPattern());
> }
> });
> [/code]
>
> As expected prints:
>
> > BBB: Exchange Pattern is: InOnly
> > AAA: Exchange Pattern is: InOut
>
> So is the ExchangePattern just a FLAG which the called endpoints can wrap
> logic around or ignore?
>
>
>
> Ranx wrote
> > I'm not even sure what an InOnly to a direct endpoint means quite frankly
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788063.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
