Generalize Parameter Mapping Conventions for the Messaging Gateway [INT-2629]

[spring-operator]

Gary Russell opened INT-2629 and commented

#6588 described an issue with the assumptions made during gateway parameter mapping.

Work on the issue uncovered some edge/corner cases that could not easily be addressed without breaking possibly existing situations.

Possible solutions:

1. Do away with mapping by convention, except in the simplest of cases; requiring explicit mapping (annotation or expression/headers in XML)
2. Allow a NullPayload of some kind
3. Comprehensive convention-based mapping
4. ...

---

Affects: 2.2 M2

Issue Links:

• Can't use payload-expression that's a Map when the Map's key is not a String. [INT-2610] #6588 Can't use payload-expression that's a Map when the Map's key is not a String.

• Extend GatewayProxyFactoryBean to allow mapping of method name to Header value and to create a Map of method parameters [INT-882] #4889 Extend GatewayProxyFactoryBean to allow mapping of method name to Header value and to create a Map of method parameters

• Annotation based method-to-message mapping is inconsistent with XML based mapping [INT-2634] #6608 Annotation based method-to-message mapping is inconsistent with XML based mapping

• GatewayProxy does not keep track which method triggered the message flow [INT-3069] #7026 GatewayProxy does not keep track which method triggered the message flow

[spring-operator]

Oleg Zhurakousky commented

Here is the summary of what's going on

Here are the 3 scenarios which make it complicated

1. void foo(Map<String, ?> mapA) - currently map is resolved to a payload

2. void foo(Map<Object, ?> mapB, Map<String, ?> mapA) - currently is an exception which is a bug that is fixed. So, mapA is now headers and mapB is a payload.

3. void foo(Map<String, ?> mapB, Map<String, ?> mapA) - currently mapB is a payload and mapA is headers. However this is where things start to become inconsistent. In one of the conversation regarding empty payload you mentioned that you didn't want the map that fits payload criteria to be shifted to headers since it also meets headers criteria when the new argument which only meets the payload criteria is introduced. But as you can see modified text (testing) #2 and removed inappropriate.txt #3 demonstrate exactly that.
   And this is where things fall apart even further. The modified text (testing) #2 has no ambiguity and mapping is strictly based on which argument fits one of the two Message properties (e.g., payload or headers), but removed inappropriate.txt #3 does have an ambiguity since both arguments fit payload criteria and both fit headers criteria and the mapping is strictly based on the order of arguments only. I am sure we'd all agree that this is not a good thing to depend on.

In retrospect mapping by convention would probably need to be undone (with the exception of a single argument).

However as an alternative I still think it could be salvaged while also adding some additional value.

First, since we've been asked about empty payloads numerous times I still believe that
#1 should be mapped to headers with empty payload
#2 should be mapped as described
#3 should marge two maps into headers (and we can provide an optional override flag if two maps happen to contain the same key) and empty payload.

And with that we'll have no ambiguity. Yes we still need to decide how to represent an empty payload, but i guess first we need to agree that we need it in the first place. So I'll cast the first Yay vote ;) (and I can point to many paragraphs in the EIP book where its mentioned or implied)

Also realize that #1 is a corner case and the impact of such breaking change is very minimal since the workaround is available today with both Annotation and XML and we have plenty of cases like this today where we knowingly introduce a breaking change in a minor release to make things right/better especially if its impact is very minimal with simple workaround available and are well known by the existing users.

[spring-operator]

Oleg Zhurakousky commented

Another interesting case

XML:
<int:method name="send4" request-channel="input" payload-expression="new java.lang.Object[]{#args[0]}"/>

Gateway method:
void send4(Map<String, ?> map);

Resulting Message:
[Payload=[Ljava.lang.Object;@25cbfa42][Headers={timestamp=1340205897965, id=e2746ea4-f0ce-4342-888f-11881753afca, foo=FOO}]

As you can see the payload contains the same Map that was also mapped as headers and since there is no way for me to know what the expression will evaluate too i can't exclude this Map form being mapped as headers as well.

Obviously for this specific scenario I can check for a single argument which I just did, but the issue will remain for multiple. For example:
XML:
<int:method name="send5" request-channel="input" payload-expression="new java.lang.Object[]{#args[0], #args[1]}"/>
Method:
void send5(Map<String, ?> mapA, Map<String, ?> mapB);

At this point we are going to have to live with this duplication and the real fix would have to wait till the major overhaul of Gateway method mappings

[spring-operator]

Gary Russell commented

PR: #930