This and other process-related patterns (Process Manager, Composed Message Processor) might be deferred to 2.0.

I have been experimenting with a global "reply-fowarding" channel to encapsulate the logic that is currently in the AbstractMessageHandler's "resolveReplyChannel()" method (and possibly using the same for error-channel determination).

One advantage of such an approach is that we would have a single isolated strategy for dealing with replies (or output-channel or nullChannel, etc). If we follow that path, we might be able to add "routing slip" or "itinerary" support there as well (e.g. first look for a ROUTING_SLIP header... it could be a Queue or Stack).

I've prototyped a version of this that is based upon a MessageChannel "proxy" implementation that is set as the "replyChannel" in the MessageHeaders. That proxy keeps track of the index (based on an actual send() call to the replyChannel... i.e. at the end of a message flow/pipeline), and then it ultimately (when the routing slip channel names have all been used) sends to the actual replyChannel.

Updating the issue with a target of RC1.

I have something very similar locally, and Git makes it fairly easy to share.

One concern I found interesting to address is retry semantics (e.g.making sure that if sending a message to one of the destinations on the RoutingSlip fails, and there is a retry strategy, the retry will send the message to the same destination as before).

moving to 2.1 M1

Marius – would you be able to share your local implementation of this?

Guys,

Is anybody who is involved in implementation of this issue, or I can boldly take care of it?

Cheers

Merged.