если спринг - то да, так можно

можно еще @Component не писать, а делать это в java-config

@Bean fun b(a: A) = B(a)

Ну вообще класс придётся пометить как компонент в который будешь инжектить

С @Bean - нет

бин сам по себе добавит B в контекст

а вот дальше его надо из контекста досттаь

не понял что ты написал

вот у меня есть A, B, C... и класс конфигурции в конфиге я пишу @Bean fun b(a: A) = B(a) и все

fun b создаст бин и положит его в контекст

вот у меня есть A, B, C... и класс конфигурции в конфиге я пишу @Bean fun b(a: A) = B(a) и все

сами бины не знают про спринг ничего

бин B не инжектинится никуда если ты не пометишь таргет класс аннотацией

@Bean fun b(a: A) = B(a) @Component class C(val b: B)

Вот так будет работать

а можно вот так, и все будет работать: class A class B(val a: A) class C(val a: A, val b: B) @Bean fun a() = A() @Bean fun b(a: A) = B(a) @Bean fun c(a: A, b: B) = C(a, b)

Потом выкинуть спринг, и заменить на бутик будет проще)

эээ, ну и как потом ты эти классы a,b,c будешь использовать? ))

да, в @Bean всё придёт что надо

но и дальше что? ))

они так же будут в контексте лежать, как и то что @Component/@Service/@Controller пометил

а есть Kotlin Spring?

Есть, офф саппорт от спринга для котлина

в 5.0 будет точнее

rhenj)

круто)

ну и котлин запилили плагины для компилятора kotlin-spring kotlin-noarg ...

в 5.0 будет точнее

а когда 5.0 выйлет?

когда и java9

/stat@combot

combot.org/chat/-1001032833563

когда и java9

А если еще раз отложат? :D

я про то что если ты напишешь class C(val a: A, val b: B) в ваакуме - то магии не будет, надо класс проаннотировать всё равно что бы туда инжектнулось

А если еще раз отложат? :D

Ну у них какой то план Б есть.

Выпустить RC2 например

я про то что если ты напишешь class C(val a: A, val b: B) в ваакуме - то магии не будет, надо класс проаннотировать всё равно что бы туда инжектнулось

Ну я же вроде ясно сказал, что можно вместо аннотаций писать в конфиге. А так понятно что спринг не догадается что вон там лежит бин, в вакууме

Ну про это одно и тоже или я не понял вопроса, @component нужна если хочешь получить инжект, @bean если нужно создать объект

Ну провайдер и просто бин

если хочется бины которые ничего не знают о спринге - просто используй провайдер (@Bean)

ну если всё приложение в одном классе то да

Да не обязательно, таким образом можно отключить нафиг компонент скан и ускорить стартап)

Я вот люто плюсую за java-конфик и против @Components

Компонент скан это не по джедайски

да ок, пусть будет всё по джедайски, создавать бины как угодно можно. Вопрос же был как инжектнуть эти созданные бины

то что насоздавать бины через @bean и там всё будет збс - это хорошо, спору нет

Так инжектить их нужно прямо в другие методы создания бинов джаваконфига

в функцию-провайдер инжектить :) @Bean fun c(a: A, b: B) = C(a, b)

Вот, Руслан дело говорит

можно еще @Component не писать, а делать это в java-config

писанины много

ребятки, ну вот простой пример, есть @RestController

писанины много

ага, поэтому мне нравится как в джусе это сделано)

у Guice разве не компонент скан?

я пометил им класс, и всё в конструктор пришло, и задно рест во все методы

у Guice разве не компонент скан?

нет конечно, по дефолту там модули, в модулях биндинги и все в общем-то

ну вот в примере что я привел, там нет модулей

ну и бины и сервисы которые пришли к нему в конструктор я создал как белый парень, через java config

биндинги ж только для интерфейсов, не?

ну и бины и сервисы которые пришли к нему в конструктор я создал как белый парень, через java config

и всё счастливы по-моему

а если бинов тысячи? не устанешь их описывать?

биндинги ж только для интерфейсов, не?

канонический пример джуса binder.bind(BuildInfoService.class).to(BuildInfoServiceImpl.class).in(Singleton.class); binder.bind(CayenneService.class).to(CayenneServiceImpl.class).in(Singleton.class);

Да, простите за Impl)

а если бинов тысячи? не устанешь их описывать?

значит ты делаешь что то не так

и всё счастливы по-моему

Ты мог и сам контроллер создать в джава конфиге

а если бинов тысячи? не устанешь их описывать?

нет, в джусе нет

значит ты делаешь что то не так

ок, сотня бинов. это такое себе маленькое приложение

ну, для этого бины обычно разбивают по разным конфигурациям

Ты мог и сам контроллер создать в джава конфиге

мог бы, но такие штуки смысла держать там нет

всё что может жить без спринга – должно жить без спринга как можно дольше

но не наоборот

хм. пытался собрать небольшую jar, а мне высерает no main manifest attribute. думал я рукажоп, так скачал https://github.com/JetBrains/kotlin-examples/tree/master/gradle/hello-world java -jar kotlin-examples/gradle/hello-world/build/libs/hello-world.jar no main manifest attribute, in kotlin-examples/gradle/hello-world/build/libs/hello-world.jar wtf?

как ты собирал?

gradle clean build

ага, а кто Main-Class пропишет в манифест?

А зависимости кто в класс пас положит?

gradlew run

apply plugin: 'application' mainClassName = 'demo.HelloWorldKt' этого мало?

buildscript { repositories { jcenter() } dependencies { classpath("com.github.jengelman.gradle.plugins:shadow:1.2.4") } } apply plugin: "com.github.johnrengelman.shadow"

в зависимости от задачи fat-jar может быть лучше

apply plugin: 'application' собирает zip/tar/folder где будет app_name.sh/app_name.bat

для спринг-бута, у бутового плагина есть bootRepackage

у shadow плагина таска называется shadowJar

а у application - distZip/disTar (afaik)

у бута поприятней инфраструктура для фэтджара

у меня просто есть приложуха и там плагин "org.springframework.boot" видимо это делает за меня

?

у меня просто есть приложуха и там плагин "org.springframework.boot" видимо это делает за меня

еще как делает

вот так вот, пользуешься бутом и не знаешь how things works

бут для того и нужен, чтобы когда жареный петух клюнет, ты вообще ничего не смог понять из того, что проихсодит

у бута поприятней инфраструктура для фэтджара

ну это тот же shadow плагин

ну это тот же shadow плагин

нет

а ты про то что boot-jar умеет в линукс-сервисы?

у него своя инфраструктура и даже со своим класслоадером специальным

не только

так а смысл своего класслодера

чтобы грузить либы из специальной папочки в Jar-нике

но shadow просто разворачивает все в один джар, и тогда не нужно это

он либы не сваливает в одну, а кладет их прямо в виде jar-ок в одну jar-ку

но shadow просто разворачивает все в один джар, и тогда не нужно это

ну да, это причины для бесконечного чила проблем

например?)