I had this feature in mind for a long time, but this seems that autowiring of Kotlin top level functions is straightforward and require no reflection, but just leveraging Kotlin type system.
inlinefun <reifiedT : Any> BeanDefinitionDsl.bean(crossinlinef: Function0<T>): Any = context.registerBean { f.invoke() }
inlinefun <reifiedA : Any, reifiedT : Any> BeanDefinitionDsl.bean(crossinlinef: Function1<A, T>): Any = context.registerBean { f.invoke(context.getBean()) }
inlinefun <reifiedA : Any, reifiedB : Any, reifiedT : Any> BeanDefinitionDsl.bean(crossinlinef: Function2<A, B, T>): Any = context.registerBean { f.invoke(context.getBean(), context.getBean()) }
// To be defined the number of parameter we want to support
A typical use case is autowiring of router parameters, for example:
This commit updates Kotlin beans DSL in order to support
creating beans using callable references with autowired
parameters. Type resolution is implemented using Kotlin
reified type parameters without requiring reflection.
Closesspring-projectsgh-21845
sdeleuze
added a commit
to sdeleuze/spring-framework
that referenced
this issue
Mar 27, 2019
This commit updates Kotlin beans DSL in order to support
creating beans using callable references with autowired
parameters. Type resolution is implemented using Kotlin
reified type parameters without requiring reflection.
Closesspring-projectsgh-21845
sdeleuze
added a commit
to sdeleuze/spring-framework
that referenced
this issue
Mar 27, 2019
This commit updates Kotlin beans DSL in order to support
creating beans using callable references with autowired
parameters. Type resolution is implemented using Kotlin
reified type parameters without requiring reflection.
Closesspring-projectsgh-21845
Sébastien Deleuze opened SPR-17312 and commented
I had this feature in mind for a long time, but this seems that autowiring of Kotlin top level functions is straightforward and require no reflection, but just leveraging Kotlin type system.
A typical use case is autowiring of router parameters, for example:
That would be a very nice Spring Framework 5.2 feature IMO ;-)
No further details from SPR-17312
The text was updated successfully, but these errors were encountered: