INT-4207: Fallback for replyChannel Resolution

JIRA: https://jira.spring.io/browse/INT-4207

Enhance `AbstractMessageProducingHandler` to fallback for `replyChannel` to the `reply` if it is `Message`.
That lets to avoid extra `bridge` configuration afterwards to make that `reply` as `request` for the same `replyChannel` resolution.

This situation happens in case of error handling when the request message is `ErrorMessage`, typically without original headers to properly consult.
But at the same time `failedMessage` in the `MessagingException` has all required headers.
This commit is contained in:
Artem Bilan
2017-01-12 18:40:32 -05:00
committed by Gary Russell
parent fd082db245
commit 129ebdc625
3 changed files with 56 additions and 4 deletions

View File

@@ -34,12 +34,13 @@ To determine the reply channel, it will first check if an "output-channel" was p
ref="somePojo" method="someMethod"/>
----
If the method returns a result and no "output-channel" is defined, the framework will then check the Message's `replyChannel` header value.
If the method returns a result and no "output-channel" is defined, the framework will then check the request Message's `replyChannel` header value.
If that value is available, it will then check its type.
If it is a`MessageChannel`, the reply message will be sent to that channel.
If it is a `String`, then the endpoint will attempt to resolve the channel name to a channel instance.
If the channel cannot be resolved, then a `DestinationResolutionException` will be thrown.
It it can be resolved, the Message will be sent there.
If the request Message doesn't have `replyChannel` header and and the `reply` object is a `Message`, its `replyChannel` header is consulted for a target destination.
This is the technique used for Request Reply messaging in Spring Integration, and it is also an example of the Return Address pattern.
If your method returns a result, and you want to discard it and end the flow, you should configure the `output-channel` to send to a `NullChannel`.