Skip to content
Branch: master
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
..
Failed to load latest commit information.
gradle/wrapper
src
.gitignore
CODE_OF_CONDUCT.adoc
README.adoc
build.gradle
gradle.properties
gradlew Make `gradlew` executable Sep 24, 2019
gradlew.bat
publish-maven.gradle
settings.gradle

README.adoc

Spring Integration Kotlin DSL

This project is a Kotlin extension for 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:

@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:

@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:

@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:

@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:

@Bean
fun convertFlow() =
    integrationFlow("convertFlowInput") {
        convert<TestPojo>()
    }
You can’t perform that action at this time.