Я правильно понимаю что в примере про Color в решении с Supplier это по сути просто такая фабрика объектов. При этом полученные колоры не будут "спринг-бинами" и аннотации над Color не будут работать. Т.е. запрашивать у контекста новый колор будет правильнее.
Может неактуально, но другим полезно будет. Нет, не правильно понимаете. Они именно спринг бины и аннотации работают. Я тестил так. Создал отдельный класс CustomColor (обертка обычного Color) с методом @PostConstruct, в котором просто принтил color. И дальше в конфиге то же самое, только color() возвращал Color, завернутый в CustomColor и метод colorSupplier() возвращал Supplier. При работе PostConstruct отрабатывал при каждом создании вызове colorSupplier.get(), то есть создавался бин, т.к. Scope - prototype. Если убрать scope, то опять цвет везде будет один и тот же. Так происходит, потому что вызов методов, аннотированных @Bean перехватывается и они не работают как просто вызов методов.
Отличное выступление! Редко такой качественный контент встретишь) Правда Спринг развивается. И немного инфа устаревает:( Как понимаю, с версии 4.3 ситуация с листами починена. List без проблем инжектится, хотя, если будут простые стринги, как в примере, Спринг все равно отдаст им предпочтенее. А в версии 3 действительно выбрасывалось IllegalArgExc, в 4-ке до 4.3 - уже NoSuchBeanDefExc
@@al1as643 Spring Boot 2.7.7 отдает предпочтение отдельным бинам, из которых сам строит лист. Если не находит ни одного отдельного бина, но присутствует бин с типом лист - заинжектится.
удивительный пробел со стороны разрабов Spring, они пилят java конфиги, при этом beanDefinition не получает всей той же информации, что из xml конфигов или аннотированных классов(@Component), и нормально, никто не задумался о "целостности данных", о единой работе интерфейсов, нет имени класса и нет, "зачем вам это нужно..."
Последние 5 минут доклада (про фабрику) я вообще не понял пока. В остальном - супер, спасибо большое за ваши доклады.
Я правильно понимаю что в примере про Color в решении с Supplier это по сути просто такая фабрика объектов. При этом полученные колоры не будут "спринг-бинами" и аннотации над Color не будут работать. Т.е. запрашивать у контекста новый колор будет правильнее.
Может неактуально, но другим полезно будет. Нет, не правильно понимаете. Они именно спринг бины и аннотации работают. Я тестил так. Создал отдельный класс CustomColor (обертка обычного Color) с методом @PostConstruct, в котором просто принтил color. И дальше в конфиге то же самое, только color() возвращал Color, завернутый в CustomColor и метод colorSupplier() возвращал Supplier. При работе PostConstruct отрабатывал при каждом создании вызове colorSupplier.get(), то есть создавался бин, т.к. Scope - prototype. Если убрать scope, то опять цвет везде будет один и тот же.
Так происходит, потому что вызов методов, аннотированных @Bean перехватывается и они не работают как просто вызов методов.
Отличное выступление! Редко такой качественный контент встретишь)
Правда Спринг развивается. И немного инфа устаревает:( Как понимаю, с версии 4.3 ситуация с листами починена. List без проблем инжектится, хотя, если будут простые стринги, как в примере, Спринг все равно отдаст им предпочтенее. А в версии 3 действительно выбрасывалось IllegalArgExc, в 4-ке до 4.3 - уже NoSuchBeanDefExc
Вроде наоборот заинжектит именно лист, если он будет, а уже только потом стринги.
@@al1as643 Spring Boot 2.7.7 отдает предпочтение отдельным бинам, из которых сам строит лист. Если не находит ни одного отдельного бина, но присутствует бин с типом лист - заинжектится.
Где первую часть посмотреть?
Вероятно тут: th-cam.com/video/U8MtGYa04v8/w-d-xo.html
удивительный пробел со стороны разрабов Spring, они пилят java конфиги, при этом beanDefinition не получает всей той же информации, что из xml конфигов или аннотированных классов(@Component),
и нормально, никто не задумался о "целостности данных", о единой работе интерфейсов, нет имени класса и нет, "зачем вам это нужно..."
Сразу пошел гуглить naya technologies