Add generic arg to the GatewayProxyFactoryBean (#3925)
* Add generic arg to the `GatewayProxyFactoryBean` Related to https://github.com/spring-projects/spring-integration/issues/3923 When gateway proxy is declared manually, a `GatewayProxyFactoryBean` is used as a `@Bean`. In this case the info about target interface is not available on a `BeanDefinition`, unlike with a programmatic registration via `MessagingGatewayRegistrar`. * Expose `<T>` on a `GatewayProxyFactoryBean` to make end-user to specify the type this gateway is going to be based on. This allows Spring container to determine the type of the `FactoryBean` bean definition properly * Migrate a programmatic bean definition registration from the `FactoryBean.OBJECT_TYPE_ATTRIBUTE` to the `targetType` property of the `BeanDefinition` based on a `ResolvableType.forClassWithGenerics()` to simulate generic arg for the application context * Remove `ComponentsRegistration` from the `GatewayProxySpec` since it us out of use * Fix affected tests for newly added generic arg on the `GatewayProxyFactoryBean` * Fix another typo in gateway.adoc Co-authored-by: Gary Russell <grussell@vmware.com> Co-authored-by: Gary Russell <grussell@vmware.com>
This commit is contained in:
@@ -312,7 +312,7 @@ public interface TestGateway {
|
||||
IMPORTANT: Similarly to the XML version, when Spring Integration discovers these annotations during a component scan, it creates the `proxy` implementation with its messaging infrastructure.
|
||||
To perform this scan and register the `BeanDefinition` in the application context, add the `@IntegrationComponentScan` annotation to a `@Configuration` class.
|
||||
The standard `@ComponentScan` infrastructure does not deal with interfaces.
|
||||
Consequently, we introduced the custom `@IntegrationComponentScan` logic to fine the `@MessagingGateway` annotation on the interfaces and register `GatewayProxyFactoryBean` instances for them.
|
||||
Consequently, we introduced the custom `@IntegrationComponentScan` logic to find the `@MessagingGateway` annotation on the interfaces and register `GatewayProxyFactoryBean` instances for them.
|
||||
See also <<./configuration.adoc#annotations,Annotation Support>>.
|
||||
|
||||
Along with the `@MessagingGateway` annotation you can mark a service interface with the `@Profile` annotation to avoid the bean creation, if such a profile is not active.
|
||||
@@ -857,7 +857,7 @@ Consequently, if you do not explicitly set the `reply-timeout`, your gateway met
|
||||
So, to make sure you analyze your flow and if there is even a remote possibility of one of these scenarios to occur, you should set the `reply-timeout` attribute to a "'safe'" value.
|
||||
Even better, you can set the `requires-reply` attribute of the downstream component to 'true' to ensure a timely response, as produced by the throwing of an exception as soon as that downstream component returns null internally.
|
||||
However, you should also realize that there are some scenarios (see <<long-running-process-downstream,the first one>>) where `reply-timeout` does not help.
|
||||
That means it is also important to analyze your message flow and decide when to use a synchronous gateway rather than an asynchrnous gateway.
|
||||
That means it is also important to analyze your message flow and decide when to use a synchronous gateway rather than an asynchronous gateway.
|
||||
As <<async-gateway,described earlier>>, the latter case is a matter of defining gateway methods that return `Future` instances.
|
||||
Then you are guaranteed to receive that return value, and you have more granular control over the results of the invocation.
|
||||
Also, when dealing with a router, you should remember that setting the `resolution-required` attribute to 'true' results in an exception thrown by the router if it can not resolve a particular channel.
|
||||
|
||||
Reference in New Issue
Block a user