2009/4/19 Frank Schwarz <[email protected]>: > > Hi, > > I am trying to realize a composed message processor - without luck so far. > > The messages get perfectly split, but I am not sure, how to realize the > aggregation later on. > > Is there any built-in correlation criteria for the aggregation? > > The documentation (http://camel.apache.org/splitter.html) says: > CamelSplitIndex: Camel 2.0: A split counter that increases for each Exchange > being split. The counter starts from 0. > > How shall I read this line? > (a) For each composed message that is split, every item (that results from > the split) gets the _same_ value for the header "CamelSplitIndex". For the > next composed message to be split, this counter is increased by 1. > (b) For each split item from a composed message the header "CamelSplitIndex" > is increased by 1. With every new composed message to be split, this counter > start from 0. > > I understand the documentation as (a) but what I observe is (b). > > What is the correct reading? What is the intended behavior?
Intended behavior and the implemented one is (b) > If (b), why does the splitter not insert a correlation header for the > aggregation later on? There is no correlation header, because if you want to aggregate split messages back, then splitter has a built in aggregator, that simply aggregates parts that it sent - there is no reason for additional correlation id when it knows identities of those exchanges. Of course it means that splitter works in in-out mode and you provided aggregation strategy. Of course you can provide your own correlation id for some future aggregation of those messages, but this is your choice, so you provide your own way of correlation. Camel doesn't force you to aggregate things the same way as they were split. For details of usage refer to http://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/SplitterTest.java I hope my explanation helps a little, Roman
