Make `SendToMethodReturnValueHandler` and `SubscriptionMethodReturnValueHandler` customizable, to allow for pass-through of message headers

[JohnHaze]

SendToMethodReturnValueHandler, SubscriptionMethodReturnValueHandler shall be customizable, in order to be able to pass through configured message headers of handled input messages.

Now: all message headers of input messages are discarded by mentioned ReturnValueHandlers.

Assuming a possibility to configure these handlers, it may be feasible to let message headers carried by input messages pass through into the messaging system while still using mentioned ReturnValueHandlers.
For example, this comes in handy for implementing receipt-header-assisted communication between producers and consumers.
Also, pass-through of other proprietary headers may enhance application implementations.

References:

@JohnHaze I do see how copying all headers fits well for a controller method that intercepts a message before forwarding it to the broker, but I can also see a case where the controller method handles the message, and sends a new one. Therefore I'm not sure this should be done always, but it does make sense to provide control and allow you to do this.

Could you create a new issue, and we'll look for a way to make SendToMethodReturnValueHandler and SubscriptionMethodReturnValueHandler customizeable?

Originally posted by @rstoyanchev in #16664

#16664 (comment)

[catturtle123]

Hi @rstoyanchev,

I noticed you’ve assigned this issue to yourself for the 7.0.4 milestone. If you haven’t started working on it yet, would you be open to having me contribute a PR for this?

Before diving into the implementation, here is the direction I have in mind:

Rather than a simple boolean flag, I propose an opt-in customization point to selectively propagate specific headers (e.g., correlation or receipt headers), while avoiding accidental copying of internal protocol headers.

Specifically, I'm thinking of adding a small hook (for example, a BiConsumer<MessageHeaders, MessageHeaderAccessor>) to SendToMethodReturnValueHandler and SubscriptionMethodReturnValueHandler. This would allow applications to map input message headers to output headers during the header creation phase.

If this direction aligns with your plans, let me know and I will prepare a PR including unit tests updates.

[rstoyanchev]

@catturtle123 that sounds reasonable, but possibly more advanced (hands on) than needs to be, and at the same time there might be other bits of information that are important to know like the controller method.

I think it would be better to start with a simpler option, for example by providing an option to configure a list of headers to propagate by name. This could be in the form of one or more Predicate<String>s combined with or that help to filter header names. That would allow propagating specific headers only, or all headers, or somewhere in between.

In the future we can consider additional requests based on specific requirements. Let me know if you plan to prepare a PR along those lines.

[catturtle123]

Thanks, sounds good. I’ll prepare a PR along those lines.

[catturtle123]

I've submitted a PR to address this issue.

PR: #36179