Support header setting on gateways that initiate a DSL flow

[garyrussell]

@MessagingGateway(defaultHeaders = @GatewayHeader(name = "method", expression = "#gatewayMethod.name"))
interface Gate {

	void method1(String foo);

	void method2(String foo);

}

Doesn't work -

Caused by: java.lang.IllegalStateException: send is not supported, because no request channel has been configured

We need some mechanism to set headers so we can do something like...

@Bean
public IntegrationFlow flow() {
	return IntegrationFlows.from(Gate.class)
			.route(...)
			.get();
}

See https://stackoverflow.com/questions/57709118/what-is-analog-of-intgateway-xml-tag-in-java-dsl-in-spring-integration/57710401#57710401

[garyrussell]

Maybe using MessagingGateway is not correct because it also might be picked up by a scan.

[artembilan]

We have a test-case like this ContentTypeConversionTests:

@MessagingGateway
interface ServiceGateway {

	@Gateway(headers = @GatewayHeader(name = MessageHeaders.CONTENT_TYPE, value = "application/json"))
	TestPerson convertJsonToPerson(String jsonPerson);

	String mapToString(Map<?, ?> map);

}
...
@Bean
public IntegrationFlow serviceFlow() {
	return IntegrationFlows.from(ServiceGateway.class)
			.channel("serviceChannel")
			.handle(this)
			.get();
}

and when I add that (defaultHeaders = @GatewayHeader(name = "method", expression = "#gatewayMethod.name")) into the @MessagingGateway I see this in the debug:

 payload = "{"firstName":"John","lastName":"Doe","age":42}"
 headers = {MessageHeaders@3965}  size = 6
  "replyChannel" -> {GenericMessagingTemplate$TemporaryReplyChannel@3975} 
  "errorChannel" -> {GenericMessagingTemplate$TemporaryReplyChannel@3975} 
  "id" -> {UUID@3978} "a1537c91-d59b-e39e-6655-bf940116506f"
  "method" -> "convertJsonToPerson"
  "contentType" -> "application/json"
  "timestamp" -> {Long@3984} 1567097310162

So, what am I missing? The fact that @MessagingGateway interface is scanned by the @IntegrationComponentScan?
There is an excludeFilters option on that annotation to let you do not process an interface which is used from DSL.

If we talk about some extra headers for use-cases like IntegrationFlow.from(Function.class), then I don't see problems just using an enrichHeaders() as the next endpoint.

You may not use @MessagingGateway on the interface to avoid scanning, but you can use @Gateway on the methods to populate some method-specific headers.

Although I think we may add an overloaded IntegrationFlow.from(Class<?>) to populate additional common gateway options if that is so confusing with the @IntegrationComponentScan...
Or we can just disable a @MessagingGateway to be used from DSL in favor of fine-grained configuration and @IntegrationComponentScan. Again: to avoid such a confusion.

[garyrussell]

OK; that's fine; I didn't test @Gateway - I just assumed we'd get the same error.

[garyrussell]

We can't use enrichHeaders because we don't have the gatewayMethod variable there.

[artembilan]

What is the point to use gatewayMethod for Function interface at all?
As I said: if it is your interface, you are good to add @Gateway on your methods for such headers.
Or, of course, you can use @MessagingGateway on the interface, but don't use @IntegrationComponentScan (or exclude). Or opposite: do not use this interface in the IntegrationFlows.from() but route to the flow by the requestChannel from the interface.

I would say that IntegrationFlows.from() is more about third-party interfaces, like java.util.function.Function just because it is too complicate to configure everything via GatewayProxyFactoryBean and it is impossible to have it via @MessagingGateway.

[garyrussell]

You said...

If we talk about some extra headers for use-cases like IntegrationFlow.from(Function.class), then I don't see problems just using an enrichHeaders() as the next endpoint.

That way there is no way to get information about the source method.

As I said, if it works on @Gateway it's ok; I just wanted to clear up this point.

[artembilan]

Reopen, since we have agreed that it would be better to populate something like gatewayMethod header unconditionally.
Perhaps an additional header for original method arguments would be great, too...