Spring/spring-integration
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

INT-4565: Fix IntComponentScan for profiles (#2652)

Browse Source 
* INT-4565: Fix IntComponentScan for profiles

JIRA: https://jira.spring.io/browse/INT-4565

* Propagate an `Environment` to the internal `ClassPathScanningCandidateComponentProvider`
in the `IntegrationComponentScanRegistrar` for proper profiles activation
* Ensure the logic works in the `GatewayInterfaceTests`
* Some polishing and performance improvement for the `GatewayInterfaceTests`
* Add a note about `@Profile` in the `gateway.adoc`
* Polishing for the `gateway.adoc`

**Cherry-pick to 5.0.x & 4.3.x**

* * Add not activated by profile gateway interface into the `GatewayInterfaceTests`
* More `GatewayInterfaceTests` polishing
* Fix typo in the `gateway.adoc`

* Fix Checkstyle violation

# Conflicts:
#	spring-integration-core/src/test/java/org/springframework/integration/gateway/GatewayInterfaceTests.java
#	src/reference/asciidoc/gateway.adoc

# Conflicts:
#	spring-integration-core/src/test/java/org/springframework/integration/gateway/GatewayInterfaceTests.java
This commit is contained in:
Artem Bilan
2018-12-06 15:41:40 -05:00
parent e6140a66fd
commit 7e79477b48
3 changed files with 81 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
src/reference/asciidoc/gateway.adoc
View File

@@ -283,8 +283,9 @@ The standard `@ComponentScan` infrastructure doesn't deal with interfaces, there
to determine `@MessagingGateway` annotation on the interfaces and register `GatewayProxyFactoryBean` s for them.
See also <<annotations>>
NOTE: If you have no XML configuration, the `@EnableIntegration` annotation is required on at least one `@Configuration`
class.
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.
NOTE: If you have no XML configuration, the `@EnableIntegration` annotation is required on at least one `@Configuration` class.
See <<configuration-enable-integration>> for more information.
[[gateway-calling-no-argument-methods]]
@@ -374,14 +375,11 @@ error: if there is an `error-channel` configured, it will be sent there, to the
thrown to the caller of gateway.
Similarly, if the error flow on the `error-channel` returns an `ErrorMessage` its payload is thrown to the caller.
The same applies to any message with a `Throwable` payload.
This can be useful in async situations when when there is a need propagate an `Exception` directly to the caller.
To achieve this you can either return an `Exception` as the `reply` from some service, or simply throw it.
Generally, even with an async flow, the framework will take care of propagating an exception thrown by the
downstream flow back to the gateway.
The https://github.com/spring-projects/spring-integration-samples/tree/master/intermediate/tcp-client-server-multiplex[TCP Client-Server Multiplex]
sample demonstrates both techniques to return the exception to the caller.
It emulates a Socket IO error to the waiting thread using an `aggregator` with `group-timeout` (see <<agg-and-group-to>>)
and `MessagingTimeoutException` reply on the discard flow.
This can be useful in asynchronous situations when when you need to propagate an `Exception` directly to the caller.
To do so, you can either return an `Exception` (as the `reply` from some service) or throw it.
Generally, even with an asynchronous flow, the framework takes care of propagating an exception thrown by the downstream flow back to the gateway.
The https://github.com/spring-projects/spring-integration-samples/tree/master/intermediate/tcp-client-server-multiplex[TCP Client-Server Multiplex] sample demonstrates both techniques to return the exception to the caller.
It emulates a socket IO error to the waiting thread by using an `aggregator` with `group-timeout` (see <<agg-and-group-to>>) and a `MessagingTimeoutException` reply on the discard flow.
[[async-gateway]]
@@ -514,6 +512,9 @@ In this scenario, it is expected that the downstream flow will return a `Complet
*Usage Scenarios*
In the following scenario, the caller thread returns immediately with a `CompletableFuture<Invoice>`, which is completed when the downstream flow replies to the gateway (with an `Invoice` object).
====
[source, java]
----
@@ -526,8 +527,8 @@ CompletableFuture<Invoice> order(Order order);
<int:gateway service-interface="foo.Service" default-request-channel="orders" />
----
In this scenario, the caller thread returns immediately with a `CompletableFuture<Invoice>` which will be completed
when the downstream flow replies to the gateway (with an `Invoice` object).
In the following scenario, the caller thread returns with a `CompletableFuture<Invoice>` when the downstream flow provides it as the payload of the reply to the gateway.
Some other process must complete the future when the invoice is ready.
[source, java]
----
@@ -542,8 +543,7 @@ CompletableFuture<Invoice> order(Order order);
async-executor="" />
----
In this scenario, the caller thread will return with a CompletableFuture<Invoice> when the downstream flow provides
it as the payload of the reply to the gateway.
In the following scenario, the caller thread returns with a `CompletableFuture<Invoice>` when the downstream flow provides it as the payload of the reply to the gateway.
Some other process must complete the future when the invoice is ready.
[source, java]