Commit Graph

16 Commits

Author SHA1 Message Date
Sebastien Deleuze
8b8a6766de Change BeanDefinitionDsl to implement ApplicationContextInitializer 2017-09-04 10:46:20 +02:00
Sebastien Deleuze
29c112c010 Avoid requiring it parameter in Kotlin bean DSL
By using function literals with receiver, we can avoid requiring
lambda parameters for a shorter and nicer syntax. Based on a
proposal from Joseph Taylor.

Issue: SPR-15815
2017-07-25 11:21:08 +02:00
Sebastien Deleuze
ff85726fa9 Fix warnings in Kotlin tests 2017-07-19 08:12:48 +02:00
Sebastien Deleuze
e2fd04dff3 Add a [] Kotlin extension for PropertyResolver#getRequiredProperty 2017-07-19 08:12:32 +02:00
Sebastien Deleuze
f72e0daa54 Add an env accessor to BeanDefinitionContext
Issue: SPR-15755
2017-07-19 07:57:19 +02:00
Sebastien Deleuze
1f011467b8 Introduce Kotlin functional bean definition DSL
As a follow-up of the ApplicationContext Kotlin extensions, close to
the Kotlin functional WebFlux DSL and partially inspired of the
Groovy/Scala bean configuration DSL, this commit introduces a
lightweight Kotlin DSL for functional bean declaration.

It allows declaring beans as following:

beans {
	bean<Foo>()
	profile("bar") {
		bean<Bar>("bar", scope = Scope.PROTOTYPE)
	}
	environment({ it.activeProfiles.contains("baz") }) {
		bean { Baz(it.ref()) }
		bean { Baz(it.ref("bar")) }
	}
}

Advantages compared to Regular ApplicationContext API are:
 - No exposure of low-level ApplicationContext API
 - Focused DSL easier to read, but also easier to write with a fewer
   entries in the auto-complete
 - Declarative syntax instead of functions with verbs like registerBeans
   while still allowing programmatic registration of beans if needed
 - Such DSL is idiomatic in Kotlin
 - No need to have an ApplicationContext instance to write how you
   register your beans since beans { } DSL is conceptually a
   Consumer<GenericApplicationContext>

This DSL effectively replaces ApplicationContext Kotlin extensions as
the recommended way to register beans in a functional way with Kotlin.

Issue: SPR-15755
2017-07-12 16:38:41 +02:00
Sebastien Deleuze
d728d597f2 Add missing license headers in Kotlin files 2017-06-27 14:39:26 +02:00
Sebastien Deleuze
04d5a2951c Remove KClass based Kotlin extensions
Issue: SPR-15660
2017-06-13 18:43:59 +02:00
Sebastien Deleuze
86580b2358 Polishing 2017-06-09 01:49:56 +03:00
Sebastien Deleuze
8579ae66fc Add comprehensive tests of Kotlin extensions
This commit also removes extensions hidden by Java API (varargs).
2017-06-09 01:01:16 +03:00
Sebastien Deleuze
0a988fd2b1 Remove object wrappers in Kotlin extensions
This commit also improve significantly Kotlin extensions
documentation.

Issue: SPR-15127
2017-01-11 08:52:01 +01:00
Sebastien Deleuze
f8461d856a Support Gradle-style Kotlin bean API
val context = GenericApplicationContext {
    registerBean<Foo>()
    registerBean { Bar(it.getBean<Foo>()) }
}

Issue: SPR-15126
2017-01-10 21:43:27 +01:00
Mario Arias
1af905ca0a Add Model and ModelMap Kotlin extensions
Issue: SPR-15119
2017-01-10 14:22:54 +01:00
Sebastien Deleuze
c5cfd8c8fc Make the Kotlin bean registration API even more idiomatic
Put the lambda parameter at the end and use a function
instead of a supplier to be able to register beans like this:

val context = GenericApplicationContext()
context.registerBean(Foo::class)
context.registerBean{ Bar(it.getBean(Foo::class)) }

Issue: SPR-15118
2017-01-10 10:38:24 +01:00
Sebastien Deleuze
715274e327 Avoid the need to specify Supplier in Kotlin bean registration API
Based on an idea from Mario Arias, we can avoid requiring specifying
explicitly Supplier lambda type in Kotlin API by declaring the supplier
parameter as "crossinline supplier: () -> T" instead of
"supplier: Supplier<T>".

Issue: SPR-15118
2017-01-09 20:22:30 +01:00
Sebastien Deleuze
ff675f5226 Add Kotlin extensions for bean registration and retrieval
Issue: SPR-15048
2016-12-26 14:21:10 +01:00