You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
INT-4565: Fix IntComponentScan for profiles (#2652)
* 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
Copy file name to clipboardExpand all lines: spring-integration-core/src/main/java/org/springframework/integration/config/IntegrationComponentScanRegistrar.java
Copy file name to clipboardExpand all lines: src/reference/asciidoc/gateway.adoc
+14-14Lines changed: 14 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -283,8 +283,9 @@ The standard `@ComponentScan` infrastructure doesn't deal with interfaces, there
283
283
to determine `@MessagingGateway` annotation on the interfaces and register `GatewayProxyFactoryBean` s for them.
284
284
See also <<annotations>>
285
285
286
-
NOTE: If you have no XML configuration, the `@EnableIntegration` annotation is required on at least one `@Configuration`
287
-
class.
286
+
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.
287
+
288
+
NOTE: If you have no XML configuration, the `@EnableIntegration` annotation is required on at least one `@Configuration` class.
288
289
See <<configuration-enable-integration>> for more information.
289
290
290
291
[[gateway-calling-no-argument-methods]]
@@ -374,14 +375,11 @@ error: if there is an `error-channel` configured, it will be sent there, to the
374
375
thrown to the caller of gateway.
375
376
Similarly, if the error flow on the `error-channel` returns an `ErrorMessage` its payload is thrown to the caller.
376
377
The same applies to any message with a `Throwable` payload.
377
-
This can be useful in async situations when when there is a need propagate an `Exception` directly to the caller.
378
-
To achieve this you can either return an `Exception` as the `reply` from some service, or simply throw it.
379
-
Generally, even with an async flow, the framework will take care of propagating an exception thrown by the
380
-
downstream flow back to the gateway.
381
-
The https://github.com/spring-projects/spring-integration-samples/tree/master/intermediate/tcp-client-server-multiplex[TCP Client-Server Multiplex]
382
-
sample demonstrates both techniques to return the exception to the caller.
383
-
It emulates a Socket IO error to the waiting thread using an `aggregator` with `group-timeout` (see <<agg-and-group-to>>)
384
-
and `MessagingTimeoutException` reply on the discard flow.
378
+
This can be useful in asynchronous situations when when you need to propagate an `Exception` directly to the caller.
379
+
To do so, you can either return an `Exception` (as the `reply` from some service) or throw it.
380
+
Generally, even with an asynchronous flow, the framework takes care of propagating an exception thrown by the downstream flow back to the gateway.
381
+
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.
382
+
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.
385
383
386
384
387
385
[[async-gateway]]
@@ -514,6 +512,9 @@ In this scenario, it is expected that the downstream flow will return a `Complet
514
512
515
513
*Usage Scenarios*
516
514
515
+
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 this scenario, the caller thread returns immediately with a `CompletableFuture<Invoice>` which will be completed
530
-
when the downstream flow replies to the gateway (with an `Invoice` object).
530
+
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.
531
+
Some other process must complete the future when the invoice is ready.
In this scenario, the caller thread will return with a CompletableFuture<Invoice> when the downstream flow provides
546
-
it as the payload of the reply to the gateway.
546
+
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.
547
547
Some other process must complete the future when the invoice is ready.
0 commit comments