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

[spring-operator]

Wallace Wadge opened INT-3069 and commented

I want to try and avoid having to manually define each method in a gateway bean. My current setup is:

gateway --> (a bunch of irrelevant stuff) --> http outbound gw

Each gateway method is multiplexed to use the same HTTP outbound gw in order to unnecessarily create a bunch of HTTP gateways. To make this happen I need to pass along a URL which is unique per method. The usual way to do this would be to define each method in the XML config, setup a static header (there's no way to create a static header via annotation) and then read that off in the http outbound gateway but that would leave me defining each method which is messy.

In my interface I want to be able to just say something like:
@WebServiceCall("http://localhost/whatever")
HeartBeat getHeartbeat();

and in a later header enricher read that annotation off. There's only one thing missing: the gateway bean does not keep track which method trigged the message. If I had a {"originatingMethodCall": methodInvocation} reference then it would be trivial.

Thoughts?

Aside #1: I worked around it by making an aspect and storing what I wanted in a thread-local but that looks an unclean approach
Aside #2: This would not have been necessary if it were possible to define static headers per method as an annotation.

---

Issue Links:

• Declared methods names of the Gateway interface should be also in the header [INT-3081] #7063 Declared methods names of the Gateway interface should be also in the header
  ("is duplicated by")

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

• 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

• Add top level header expression to gateway [INT-2181] #6167 Add top level header expression to gateway
  ("supersedes")

[spring-operator]

Gary Russell commented

Perhaps a marginally cleaner work-around might be

public interface MyGateway {

	@Payload("T(java.util.Arrays).asList(new Object[] {#args[0], 'http://foo/bar'})")
	public String send(String text);

}

and

<int:chain input-channel="input" output-channel="next">
	<int:header-enricher>
		<int:header name="url" expression="payload.get(1)" />
	</int:header-enricher>
	<int:transformer expression="payload.get(0)" />
</int:chain>

But it seems we could add a method-level annotation (@Headers??) to allow specification of arbitrary headers on a method invocation.

However, in any case, you might want to use a token which is later mapped, rather than a literal URL, to avoid tight coupling between the gateway and http endpoint.

[spring-operator]

Wallace Wadge commented

I'm guessing that would be messy when dealing with gateways that mix:

• methods that result in HTTP posts
• methods that do http gets without payloads (= dummy payloads)

Anyway I believe creating a message earlier on would allow us to track the message flow better.

[spring-operator]

Wallace Wadge commented

(btw I'm referring to the spel expression, not the static method-level header annotation which I miss too)

[spring-operator]

Artem Bilan commented

Hey there!
Let me insert and my five fingers!
Wallace,

Anyway I believe creating a message earlier on would allow us to track the message flow better.

I don't think so: in this case you make your message flow less loosely-coupled. Your geteway fully knows what will be done in the doewstream.
And if you are going to change HTTP endpoint to AMQP or IP...

So, Gary is right: replace your URL-header to some token and just use XML mapping for your gateway to configure each method. It allows to avoid SI depemdencies from your gateway interface and use it anywhere in the application. And further you will be able to do routing closer to your outbound endpoint.

add a method-level annotation (@Headers??) to allow specification of arbitrary headers on a method invocation

+1 to be consistent with similar solution in the XML variant.

the gateway bean does not keep track which method trigged the message

That also makes sense: as a trigger to start a message flow. Something similar we get in the MesasgeHeaders in the HTTP, AMQP, JMS etc. inbound endpoints.

[spring-operator]

Artem Bilan commented

Related issue #6603

[spring-operator]

Wallace Wadge commented

The token idea makes a lot of sense -- I'd implement it with the method-level header annotation in place (open a new issue to track this?)

I tend to disagree on loosing the message origin source (any source, not just gateway) but I won't complain too noisily :-)

[spring-operator]

Gary Russell commented

Aside from possibly adding a @Headers method-level attribute...

It shouldn't be too hard to add a header automatically ('gw_origin_method') regardless of whether an annotation or XML was used to configure the gateway (you could then use that as your key to map to a URL ...expression=@urlMap.get(headers['gw_origin_method'])...).

However, a simple method name is probably not enough, it would need the return/argument types too

String_foo(String), String_foo(Integer), void_bar(String,String) etc.

Maybe we should make that the focus of this JIRA and open a second one to add a @Headers method-level annotation??

[spring-operator]

Wallace Wadge commented

I was thinking of storing the Method reference (as in, the class) directly in the map, that way you can extract everything else via reflection. At least for the gateway code, this is already being done, it's just not storing it anywhere.

In my case, my aspect is doing:

    @Around("execution(* com.foo.GatewayService*.*(..)) ")
    @Order(0)  // do our work before the @Gateway annotation
    public Object invoke(ProceedingJoinPoint pjp) throws Throwable {

        MethodSignature signature = (MethodSignature) pjp.getSignature();
        Method method = signature.getMethod();  
        TypeToken<?> typeToken = TypeToken.of(method.getGenericReturnType());

I then store (guava's) typeToken and use that to access anything I need (generics included)

[spring-operator]

Gary Russell commented

Maybe both might be useful (text as well as Method object).

Duplicate #7063

[spring-operator]

Artem Bilan commented

I suggest to build String representation compatible with BeanUtils.resolveSignature, e.g. foo(java.lang.String). But it doesn't support 'return type'...

[spring-operator]

Gary Russell commented

PR: #929