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
This commit is contained in:
Artem Bilan
2018-12-06 15:41:40 -05:00
committed by Gary Russell
parent 2cde493fbf
commit 536b6b1786
3 changed files with 97 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -188,7 +188,7 @@ Consider the following example:
----
public String send1(Object thing1, Map thing2);
public String send2(Map thing1, Map thing2);=
public String send2(Map thing1, Map thing2);
----
====
@@ -313,8 +313,9 @@ 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.
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]]
@@ -460,11 +461,9 @@ Similarly, if the error flow on the `error-channel` returns an `ErrorMessage`, i
The same applies to any message with a `Throwable` payload.
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.
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.
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.
[[gateway-timeouts]]
==== Gateway Timeouts
@@ -642,8 +641,7 @@ In this scenario, the downstream flow is expected to return a `CompletableFuture
====== 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).
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]
@@ -657,8 +655,7 @@ CompletableFuture<Invoice> order(Order order);
----
====
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.
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.
====
@@ -674,8 +671,7 @@ CompletableFuture<Invoice> order(Order order);
----
====
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.
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.
If `DEBUG` logging is enabled, a log entry is emitted, indicating that the async executor cannot be used for this scenario.