Spring 5 dodał nowy - bardzo wygodny - sposób konfiguracji naszych przy użyciu prostych funkcji STOP Owo podejście nie wymaga stosowania adnotacji ani manipulacji bajtkodem STOP Co więcej Spring dostarcza natywne wsparcie dla Kotlina wykorzystując jego specyficzne mechanizmy, które znacznie upraszczają kod STOP A ponieważ nie jednego flejma o technologiach widziałem to we filozofie brnąć nie będę STOP A Tutaj jak ktoś chce są opisane problemy z adnotacjami The case against annotations STOP

Skoro o kodzie mowa

Rozpoczynając prezentację - dla potrzeb naszego przykładu edukacyjnego stworzymy następująca kolekcję typów, która to kolekcja pozwoli nam zobrazować jak wygląda konfiguracja z użyciem Kotlinowego DSL-a. Jakies interfejsy, kilka 'binów' i działamy :

interface I1
interface I2
class Bean1 : I1
class Bean2(dependency:I1)
: I2
class Bean3(dependency:I2)

Aby użyć DSLka wystarczy jeden import :

No i już możemy pracować z bardzo - w moim odczuciu - przyjemnym kodem. I w moim osobistym odczuciu to naprawdę jest dosyć czytelna konfiguracja, która jednocześnie jest silnie typowana, czyli kompilator pilnuje nam pleców ,wyłapuje wszelkie babole , troszczy się itd:

beans {
    bean<Bean1>()
    bean{

val i1:I1=ref<Bean1>()
         Bean2(i1)

}
    bean("Bean3"){

val i2:I2=ref<Bean2>()
      Bean3(i2)

}
}

Powyższy fragment jest standardowym kodem Kotlina - nie ma tam żadnej magii a jedynie wykorzystanie natywnych mechanizmów języka. Deklarujemy nasze trzy beany pobierając zależności poprzez wywołanie metody. Wszystko jest kodem. Wszystko jest w jednym miejscu. Można to ogarnąć łatwo. Chaosu nie ma.

A jeżeli nie do końca jeszcze wiadomo to, by lepiej zrozumieć sytuację zerknijmy w głąb metod. Mamy tego MR. beans i wygląda to choćby przyjaźnie ale tenże argument init jakis taki dziwny. Jakieś nawiasy po kropce. Co... co się tutaj stanęło?

fun beans(init: BeanDefinitionDsl.()
->
Unit): BeanDefinitionDsl {

val beans = BeanDefinitionDsl()
    beans.init()

return beans
}

Otóż cała zabawa z tym DSLem jest możliwa dzięki zapisowi “init: BeanDefinitionDsl.() -> Unit” , który definiuje BeanDefinitionDsl jako odbiorcę wywołań w lambdzie (z engielska 'receiver'). Czyli dla przykładu we fragmencie

beans {
bean<Bean1>()
  ...
}

Mamy 'implicit this' (dokładnie tak!) i tak naprawdę, wywołujemy

beans { dsl ->
  dsl.bean<Bean1>()
  ...
}

Teraz pojedynczy 'bean'. Tutaj pojawiają się dziwne nowe słowa:

inline
fun
<reified T : Any> bean(....){....}

W tej metodzie dzieje się trochę więcej. Generalnie para słów kluczowych “inline” i “reified” w sprytny sposób zachowa informacje o typie z generyka w 'Runtime', dzięki czemu możliwe będzie utworzenie nowej instancji klasy Bean1 podanej w generyku. Podobna mechanika kryje się za metodą “ref”, która zwraca nam referencję do już zadeklarowanych beanów.

inline
fun
<reified T : Any> ref(name:
String?
=
null)
: T =

when
(name)
{

null
-> context.getBean(T::class.java)

else
-> context.getBean(name, T::class.java)
}

Zauważ drogi czytelniku/czytelniczko iż zapis “T::class.java” robi coś niesamowitego i wyciąga klasę z generyka. Magia, po prostu magia….

Chociaż nie. Nie magia a nauka.

Inicjalizacja

Caly mechanizm "beans" to tak naprawdę zwykły wzorzec builder i tak jak na klasycznym buiderze wołaliśmy “build()” lub coś podobnego na sam koniec by zapieczętować budowę - tak tutaj przekazujemy do budowy springowy kontekst. Trochę to wygląda na cykliczną zależność ale w zasadzie nie zauważyłem jeszcze z tym problemów.

val ourInit: BeanDefinitionDsl =beans {...}
    GenericApplicationContext {
    ourInit.initialize(this)
    refresh()
}

I kontekst springowy zainicjalizowany naszymi beanami. Żadnych adnotacji nie trzeba, żadnego CGLiba i majstrowania przy bajtkodzie też nie trzeba!!! Ale to nie koniec. Kotlin i Spring 5 dają nam jeszcze więcej udogodnień bo teraz
skupcie się weźta
wystawimy resta

konfiguracja REST - uważaj na przykłady Javy!

Przede wszystkim czytając tutoriale do nowego mechanizmu - jak na przykład ten https://spring.io/blog/2016/09/22/new-in-spring-5-functional-web-framework - uważaj na użytą składnie Javy, gdyż używając w identyczny sposób Kotlina możesz napotkać na pewne trudności. Otóż API dla Javy zaleca użycie funkcji “route”, która jest zdefiniowana w sposób następujący

public
static
<T extends ServerResponse> RouterFunction<T> route(
     RequestPredicate predicate, HandlerFunction<T> handlerFunction)
{

return
new DefaultRouterFunction<>(predicate, handlerFunction);
}

Gdzie "HandlerFunction" to prosty interfejs funkcyjny:

@FunctionalInterface
public
interface HandlerFunction<T extends ServerResponse>
{
  Mono<T> handle(ServerRequest request);
}

Używając tego API możemy wygodnie wpisać sobie lambdę tam gdzie oczekiwany jest HandlerFunction a to dlatego, iż Java z automatu konwertuje ową lambdę na tzw. SAM czyli klasę abstrakcyjną/interfejs z jedną metodą. Dzięki temu możemy sobie napisać route(GET(“/”),r->...) . Niestety w Kotlinie przy konwersji lambdy na typ Javy jest potrzebna dodatkowa podpowiedź dla kompilatora:

//route(GET("/test"), { r -> ok().body(Mono.just("response")) })   <- to nie pyknie
//poniżej podajemy podpowiedź, iż ta lambda to HandlerFunction i działa
route(GET("/test"), HandlerFunction { r -> ok().body(Mono.just("response"))
})

Dlatego też warto używać dedykowany DSL -wiecie taki natywny ze springa a nie żadny na boku robiony - napisany specjalnie dla Kotlina. Konstrukcja tam użyta jest podobna do tego co widzieliśmy w poprzednim odcinku dla definicji Beanów - czyli dla przypomnienia:

fun beans(init: BeanDefinitionDsl.()
->
Unit): BeanDefinitionDsl {

val beans = BeanDefinitionDsl()
  beans.init()

return beans
}

W przypadku definiowania “routingu” wygląda to bardzo ale to bardzo podobnie :

fun router(routes: RouterFunctionDsl.()
->
Unit)
= RouterFunctionDsl().apply(routes).router()
router {
   GET("/hello")
{ _ ->
       ok().body(just("Hello World!"), String::class.java)

}
}

Jak możecie chyba zgadnąć GET to nic innego jak wywołanie metody na naszym DSLu i aby było jawne, jasne i klarowne co tam się dzieje to dzieję coś takiego :

router {

val dsl:RouterFunctionDsl =
this
//<- o tutaj cała magia
   dsl.GET("/hello")
{ _ ->

//and below is HandlerFunction
       ok().body(just("Hello World!"), String::class.java)

}
}

W powyższym przykładzie GET jest po prostu wygodnym opakowaniem na to API dla Javy, o którym mówiliśmy na samym początku :

fun GET(pattern:
String, f:
(ServerRequest)
-> Mono<ServerResponse>)
{
  routes += RouterFunctions.route(RequestPredicates.GET(pattern), 
  HandlerFunction { f(it)
})
}

I problem “bojlerplejtu” rozwiązany.

Mono

Zwróć uwagę na sygnaturę funkcji przekazanej do Handlera :

Czym jest to Mono i jak wpływa na przetwarzanie requestu? O tym w innym odcinku...