Frankly, this adds quite a bit of complexity to the sendAndReceive overloads. At this point I wonder whether the previously introduced sendAndReceive methods without a SelectorType argument (#36162) are even useful on their own? If not, I'd rather revert that addition to 7.0.4, revisiting the topic for 7.1 instead.

If the selector type is commonly configured per provider, it should rather be a JmsTemplate-level setter rather than yet another sendAndReceive argument. Also, it is unusual for JmsTemplate to compose a selector expression - that might be an indication that the functionality should better live on top of JmsTemplate itself.

Well, they would kindof work - only when you use one thread to call JMS... so yeap - it might be misleading and unusable in common scenarios :/
I forgot to include these changes in first PR.

The setter thing - sure, i will move it to setter then.

Composing selector expression - it is rather hard to compose it on top of JmsTemplate as you need messageId that is only set after the message is sent.

In light of this, let's drop the "none" option and use the messageId approach by default for those sendAndReceive overloads with an explicit response queue. And for a custom correlation id, the provided MessageCreator callback can call setJMSCorrelationID if it prefers that - so we could simply check for getJMSCorrelationID in the message and use that when given, otherwise use getJMSMessageID. No need for additional overloads then and no need for a configurable enum either, and the correlation id can be built in a custom way in the MessageCreator rather than baking a UUID strategy into an enum.

@pisek I'm experimenting with my approach above, using a variation of your unit tests. No need to update the PR right now, I'll keep you posted. Let me know if you see a fundamental problem with this approach though.

I've pushed the implicit JMSCorrelationID/JMSMessageID usage as suggested above. While a JMSCorrelationID (if desired) has to be manually set in each MessageCreator, I find that flexibility preferable over a hard-coded enum mode.

From my perspective, this removes the need for the additional method overloads with the enum in this PR. Please give this a try against the latest 7.0.4 snapshot. If anything remains for this to be usable in the 7.0.4 release, let me know.