Yes, it is working as expected. If you don't set a custom Aggregation Strategy on the Splitter, as of Camel 2.3, it will return the original body by default.
Regards, *Raúl Kripalani* *Principal Consultant | FuseSource Corp. r...@fusesource.com | fusesource.com <http://www.fusesource.com/> skype: raul.fuse | twitter: @raulvk <http://twitter.com/raulvk>, @fusenews<http://twitter.com/fusenews> * blog: F3 - Flashes From the Field<http://blog.raulkr.net/?utm_source=fusesourceemail&utm_medium=email&utm_campaign=fusesourcemail> | aboutme: http://about.me/raulkripalani <http://twitter.com/fusenews> On 14 August 2012 16:16, Babak Vahdat <babak.vah...@swissonline.ch> wrote: > Hi > > I'm still a bit confused regarding a question by another thread and would > like to ask you about the point I'm missing here. > > The following test passes (e.g. using the trunk code or 2.10.0 release) > which I can follow and understand: > > public class TwoRoutesTest extends CamelTestSupport { > > @Test > public void test1() throws Exception { > getMockEndpoint("mock:result").expectedBodiesReceived("another > body"); > getMockEndpoint("mock:result2").expectedBodiesReceived("another > body"); > > template.sendBody("direct:start", "body"); > > assertMockEndpointsSatisfied(); > } > > @Override > protected RouteBuilder createRouteBuilder() throws Exception { > return new RouteBuilder() { > @Override > public void configure() throws Exception { > > from("direct:start").to("direct:process").to("mock:result"); > > from("direct:process").process(new Processor() { > @Override > public void process(Exchange exchange) throws Exception > { > Object body = exchange.getIn().getBody(); > exchange.getIn().setBody("another " + body); > } > }).to("mock:result2"); > } > }; > } > } > > Now consider the following test which is similar to the previous one but > this one would fail: > > public class TwoRoutes2Test extends CamelTestSupport { > > @Test > public void test2() throws Exception { > getMockEndpoint("mock:result").expectedBodiesReceived("a", "b", > "c"); // changing to "a,b,c" will make the test to pass > getMockEndpoint("mock:result2").expectedBodiesReceived("a", "b", > "c"); > > template.sendBody("direct:start", "a,b,c"); > > assertMockEndpointsSatisfied(); > } > > @Override > protected RouteBuilder createRouteBuilder() throws Exception { > return new RouteBuilder() { > @Override > public void configure() throws Exception { > > from("direct:start").to("direct:process").to("mock:result"); > > from("direct:process").split(body()).to("mock:result2"); > } > }; > } > } > > That's in contrast to the first test by the second test the outcome of the > second route (InOut) is not taken into the account by the direct producer > (...to("direct:producer")...) which to my understanding should have been > set > as the body of the Out Message of the current Exchange by the first route, > that's in consistence with the first test. > > Is this behaviour "worked as designed"? To me this's a bug or let's say > it's > a "not consistent". Does this behaviour have anything to do with the UoW > stuff. > > Thanks in advance for any advice > Babak > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Is-this-routing-behaviour-as-expected-tp5717331.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
