Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gateway: evaluate setting a NullChannel replyChannel in case of void return type method #3280

Closed
mauromol opened this issue May 14, 2020 · 1 comment · Fixed by #3292
Closed

Comments

@mauromol
Copy link
Contributor

Expected Behavior

The full discussion is at: https://stackoverflow.com/questions/61756786/spring-integration-gateway-with-void-method-return-type-why-doesnt-it-set-a-nu

Substantially, when I set up a gateway method with void return type, I expect that any reply message that is produced by the downstream chain is simply ignored, and that I can rather opt-in for an exception if an unexpected (?) reply message is produced.

Current Behavior

If I understand it well, right now a gateway method with void return type only works (with no exception) if the downstream chain ends with an outbound adapter or if I explicitly set a NullChannel replyChannel somewhere in the chain (perhaps with an annotation on the gateway method). Otherwise an exception is produced:

org.springframework.messaging.core.DestinationResolutionException: no output-channel or replyChannel header available

In my case I have a gateway interface with many methods and a downstream HTTP outbound gateway that invokes actions on a remote service through REST. The REST API provides some actions with a response, some others with no meaningful response (apart from a status code which is used to correctly wire errors).
On my gateway interface I would expect that a method with a void return type is enough to tell Spring Integration that I don't care about any (unmeaningful) response produced by the HTTP outbound gateway, but this is not the case and an exception is produced. I have to annotate my interface method by specifying a MessageHeaders.REPLY_CHANNEL header with nullChannel name or @nullChannel expression, or rather set this header somewhere else in my downstream chain. But this sounds redundant to me.

By debugging I see that org.springframework.integration.gateway.GatewayProxyFactoryBean.invokeGatewayMethod(MethodInvocation, boolean) does a "sendAndReceive" when the gateway method is expected to return something, otherwise a simple "send". The former call causes an appropriate replyChannel header to be set on the produced message (sorry, I'm not sure on how this is done, probably by org.springframework.integration.gateway.MessagingGatewaySupport.registerReplyMessageCorrelator()?), while the latter doesn't cause any replyChannel header to be set and hence the exception occurs if a reply message arrives from the downstream chain.

@mauromol mauromol added status: waiting-for-triage The issue need to be evaluated and its future decided type: enhancement labels May 14, 2020
@artembilan artembilan added this to the 5.4 M1 milestone May 27, 2020
@artembilan artembilan added in: core and removed status: waiting-for-triage The issue need to be evaluated and its future decided labels May 27, 2020
@artembilan artembilan self-assigned this May 27, 2020
artembilan added a commit to artembilan/spring-integration that referenced this issue May 27, 2020
Fixes spring-projects#3280

To properly support a one-way gateway (`void` return type), it is
better to ignore any possible replies from downstream instead of
unexpected `no output-channel or replyChannel header available`
error

* Populate a `nullChannel` into a `replyChannel` header
for `void` gateway methods when `replyChannel` is not set explicitly
* Remove redundant `GatewayProxyFactoryBean.PARSER` in favor of
similar `EXPRESSION_PARSER` in the super class
* Test and document the feature
garyrussell added a commit that referenced this issue May 27, 2020
* GH-3280: NullChannel as reply for void gateways

Fixes #3280

To properly support a one-way gateway (`void` return type), it is
better to ignore any possible replies from downstream instead of
unexpected `no output-channel or replyChannel header available`
error

* Populate a `nullChannel` into a `replyChannel` header
for `void` gateway methods when `replyChannel` is not set explicitly
* Remove redundant `GatewayProxyFactoryBean.PARSER` in favor of
similar `EXPRESSION_PARSER` in the super class
* Test and document the feature

* * Fix language in the `whats-new.adoc`

Co-authored-by: Gary Russell <grussell@vmware.com>

* * Fix language in gateway.adoc

Co-authored-by: Gary Russell <grussell@vmware.com>

Co-authored-by: Gary Russell <grussell@vmware.com>
@mauromol
Copy link
Contributor Author

Thank you! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants