Files
spring-integration-extensions/spring-integration-kotlin-dsl
Artem Bilan 4024a0db70 Rely on the BaseIntegrationFlowDefinition
To avoid some inline reified functions names, it would be better to rely
on the `BaseIntegrationFlowDefinition` from SI Core.
This way we can have the same names for Kotlin-specific functions
without conflicts for similar methods in Java which are just a syntax
sugar without any target type guarantee

* * Add `KotlinIntegrationFlowDefinition` as an extension of `BaseIntegrationFlowDefinition`
to be able to provide inline functions for reified generic types.
* Use this new type from the `integrationFlow()` DSL functions to avoid
extra imports for global inline functions otherwise

* * Improve README
2019-10-28 10:13:20 -04:00
..
2019-09-24 15:32:48 -04:00

= Spring Integration Kotlin DSL

This project is a Kotlin extension for https://docs.spring.io/spring-integration/docs/current/reference/html/#java-dsl[Spring Integration Java DSL].

NOTE: The project should be treated as experimental and API is a subject to changes.

The main goal we pursue here is to make Spring Integration development on Kotlin as smooth and straightforward as is it possible with interoperability with existing Java DSL and some Kotlin extensions or language-specific structures.

All you need to get started is just an import for `org.springframework.integration.dsl.integrationFlow` - an overloaded global function for Kotlin DSL.

For `IntegrationFlow` definitions as lambdas we typically don't need anything else from Kotlin and just declare a bean like this:

====
[source, kotlin]
----
@Bean
fun oddFlow() =
IntegrationFlow { flow ->
    flow.handle<Any> { _, _ -> "odd" }
}
----
====

In this case Kotlin understands that the lambda should be translated into `IntegrationFlow` anonymous instance and target Java DSL processor parses this construction properly into Java objects.

As an alternative to the construction above and for consistency with use-cases explained below, this project suggest a Kotlin-specif DSL for declaring integration flows in the *builder* pattern style:

====
[source, kotlin]
----
@Bean
fun flowLambda() =
    integrationFlow {
        filter<String>({ it === "test" })
        wireTap(
                integrationFlow {
                    handle { m -> println(m.payload) }
                })
        transform<String, String>({ it.toUpperCase() })
    }
----
====

Such a global `integrationFlow()` function expects a `@BuilderInference` for a `KotlinIntegrationFlowDefinition` (a Kotlin extension for the `BaseIntegrationFlowDefinition` with some inline function for reified generic types) and produces a regular `IntegrationFlow` lambda implementation.
See more overloaded `integrationFlow()` variants below.

Many other scenarios require an `IntegrationFlow` to be started from source of data (e.g. `JdbcPollingChannelAdapter`, `JmsInboundGateway` or just an existing `MessageChannel`).
For this purpose Spring Integration Java DSL provides an `IntegrationFlows` factory with its bunch of overloaded `from()` methods.
This factory can be used in Kotlin as well:

====
[source, kotlin]
----
@Bean
fun flowFromSupplier() =
         IntegrationFlows.from<String>({ "bar" }) { e -> e.poller { p -> p.fixedDelay(10).maxMessagesPerPoll(1) } }
                 .channel { c -> c.queue("fromSupplierQueue") }
                 .get()
----
====

But unfortunately not all `from()` methods are compatible with Kotlin structures.
To fix a gap, this project provides a Kotlin DSL around an `IntegrationFlows` factory.
It is done as a set of overloaded `integrationFlow()` functions.
With a consumer for a `KotlinIntegrationFlowDefinition` to declare the rest of the flow as an `IntegrationFlow` lambda to reuse the mentioned above experience and also avoid `get()` call in the end.
For example:

====
[source, kotlin]
----
@Bean
fun functionFlow() =
        integrationFlow<Function<String, String>>({ it.beanName("functionGateway") }) {
            transform<String, String> { it.toUpperCase() }
        }

@Bean
fun messageSourceFlow() =
        integrationFlow(MessageProcessorMessageSource { "testSource" },
                { it.poller { it.fixedDelay(10).maxMessagesPerPoll(1) } }) {
            channel { c -> c.queue("fromSupplierQueue") }
        }
----
====

In addition this project provides Kotlin extensions for Java DSL API which needs some refinement for Kotlin structures.
For example `IntegrationFlowDefinition<*>` requires a reifying for many methods with `Class<P>` argument:

====
[source, kotlin]
----
@Bean
fun convertFlow() =
    integrationFlow("convertFlowInput") {
        convert<TestPojo>()
    }
----
====