From df5f74dff182d7aa3e20f3c42943d8e4328fc02a Mon Sep 17 00:00:00 2001 From: Artem Bilan Date: Wed, 21 Aug 2019 10:03:10 -0400 Subject: [PATCH 1/3] GH-2890: Document a bridge for subflow starts Fixes https://github.com/spring-projects/spring-integration/issues/2890 Explain in a docs why and how a `bridge` appears in the flow when we declare a subflow for mapping --- src/reference/asciidoc/dsl.adoc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/reference/asciidoc/dsl.adoc b/src/reference/asciidoc/dsl.adoc index a5dbd5b3001..a5b4140fb93 100644 --- a/src/reference/asciidoc/dsl.adoc +++ b/src/reference/asciidoc/dsl.adoc @@ -816,6 +816,11 @@ When you configure a sub-flow as a lambda, the framework handles the request-rep Sub-flows can be nested to any depth, but we do not recommend doing so. In fact, even in the router case, adding complex sub-flows within a flow would quickly begin to look like a plate of spaghetti and be difficult for a human to parse. +NOTE: Any sub-flow mappings end up with a `MessageChannel` connection between an original component as a producer (e.g. a `discardChannel` in the `MessageFilter`) and the first endpoint in the sub-flow as a consumer. +When sub-flow is started with a channel, an extra `bridge()` is placed between the mapping channel and this one to make the proper flow wiring. +When an existing `IntegrationFlow` bean is used as a subflow reference, there is no such a bridge in between since the framework can resolve the first channel from the flow bean. +This information is not available yet from inline subflows. + [[java-dsl-protocol-adapters]] === Using Protocol Adapters From befdda61703a9f6641da0e9e6c6dd42d44b69e4b Mon Sep 17 00:00:00 2001 From: Artem Bilan Date: Thu, 29 Aug 2019 11:26:14 -0400 Subject: [PATCH 2/3] * Upgrade to Kotlin `1.3.50` --- build.gradle | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build.gradle b/build.gradle index 36674bcac0d..79be9f34de5 100644 --- a/build.gradle +++ b/build.gradle @@ -1,5 +1,5 @@ buildscript { - ext.kotlinVersion = '1.3.40' + ext.kotlinVersion = '1.3.50' repositories { maven { url 'https://repo.spring.io/plugins-release' } } From 0ee5e800b30209920c50be6bb47dd537a7504743 Mon Sep 17 00:00:00 2001 From: Artem Bilan Date: Thu, 29 Aug 2019 11:39:16 -0400 Subject: [PATCH 3/3] * Upgrade to Kotlin `1.3.50` * Polishing Doc according PR comments --- src/reference/asciidoc/dsl.adoc | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/src/reference/asciidoc/dsl.adoc b/src/reference/asciidoc/dsl.adoc index a5b4140fb93..0e6e16acdba 100644 --- a/src/reference/asciidoc/dsl.adoc +++ b/src/reference/asciidoc/dsl.adoc @@ -816,10 +816,23 @@ When you configure a sub-flow as a lambda, the framework handles the request-rep Sub-flows can be nested to any depth, but we do not recommend doing so. In fact, even in the router case, adding complex sub-flows within a flow would quickly begin to look like a plate of spaghetti and be difficult for a human to parse. -NOTE: Any sub-flow mappings end up with a `MessageChannel` connection between an original component as a producer (e.g. a `discardChannel` in the `MessageFilter`) and the first endpoint in the sub-flow as a consumer. -When sub-flow is started with a channel, an extra `bridge()` is placed between the mapping channel and this one to make the proper flow wiring. -When an existing `IntegrationFlow` bean is used as a subflow reference, there is no such a bridge in between since the framework can resolve the first channel from the flow bean. +[NOTE] +==== +In cases where the DSL supports a subflow configuration, when a channel is normally needed for the component being configured, and that subflow starts with a `channel()` element, the framework implicitly places a `bridge()` between the flow's input channel and that channel. +For example, in this `filter` definition: + +[source,java] +---- +.filter(p -> p instanceof String, e -> e + .discardFlow(df -> df + .channel(MessageChannels.queue()) + ...) +---- +the Framework creates internally a `DirectChannel` bean for injecting into the `MessageFilter.discardChannel`. +Then it wraps the subflow into an `IntegrationFlow` starting with this implicit channel for subscription and places a `bridge` before the mentioned `channel()` in the flow. +When an existing `IntegrationFlow` bean is used as a subflow reference, there is no such bridge in between since the framework can resolve the first channel from the flow bean. This information is not available yet from inline subflows. +==== [[java-dsl-protocol-adapters]] === Using Protocol Adapters