Настройка приложения — Spring Configuration Metadata

[tbl]

XML-конфигурация контекста, автовайринг в поля — в итоге странный учебник, учащий старым практикам работы со спрингом.

[arylkov]

Где сказано, что xml legacy. inject в privite поля это legacy, а вот в setXxx нет.

[IoannGolovko]

1. Пример с xml — очень плохо.

2. Еще не хватает объяснения, откуда появляется файл additional-spring-configuration-metadata.json и как он связан с spring-boot-configuration-processor.

3. Статьи на хабре читает много новичков; и инжект сервисов в properties, вы шутите?

И какой смысл использовать всю эту кашу с метаданными вне стартеров?

[arylkov]

— Где сказано, что xml legacy?
— additional-spring-configuration-metadata — делаем сами, если нужны hints, это клон spring-configuration-metadata.
— ограничений на типы которые можно указать в properties практически нет, сделано это как я понимаю не случайно. И типы Providers для этого сделаны тоже: class-reference, spring-bean-reference и др. Видимо разработчики spring видят в этом смысл.

[IoannGolovko]

Ответ ниже прилетел

[alek_sys]

Спасибо за статью! Пара моментов, больше для читателей, из того, что не упомянуто:

1. Самое важное — @ConfigurationProperties это не только про загрузку свойств из application.properties файла. Возможности Spring Boot Configuration гораздо шире — поддерживается 17 (!) разных источников свойств в строгом приоритете. Можно определить дефолт в application.properties и перекрыть его через переменную окружения, JVM properties, профиль, тестовые свойства и т.п. Что дает очень мощные возможности для переконфигурирования приложения в нужном окружении и сильно упрощает конфигурацию. А в дополнение — список источников еще и можно расширять, например, добавить Hashicorp Vault как бэкенд.
2. ConfigurationProperties аннотация — это часть Spring Boot, а не Spring Core
3. @SpringBootApplication аннотация включает ComponentScan, так что XML конфигурацию (да и любую конфигурацию) можно убрать и просто аннотировать классы @Component. Хотя некоторые разработчики предпочитают явную конфигурацию над автоматическим поиском компонентов.
4. Конфигурировать можно не только классы properties, а вообще любой бин — если совместить @Bean + @ConfigurationProperties или @Component + @ConfigurationProperties. По сути, все, что делает @EnableConfigurationProperties — это регистрирует бин указанного типа.
5. Field и Property injection это, все же, моветон, хотя и не запрещено.

[arylkov]

Спасибо! Интересно

[IoannGolovko]

1. Как минимум, здесь отсутствует типобезопасность.

2. Замечание не на тему того, кто чей клон, а откуда этот файл берется. Его генерирует определенный annotation processor. Кому нужно делать rebuild проекта ради какой-то подсветки? Вся эта каша нужна в библиотеках и стартерах. Или в 2018 кто-то еще зашивает конфиги в поставку?

3. Это нужно не для инжекта бизнес логики в конфиг! А для создания сложных библиотечных конфигураций, завязанных на стандартных интерфейсах из jsl или кастомной абстракции. В примере из статьи присутствует явное нарушение single responsibility principle. ConfigurationProperties нужно использовать либо в автоконфигурации, либо в сервисе, которому эти конфиги нужны (второе решение — так себе). Код из примера можно понять таким образом (а ведь он именно и написан в таком стиле), что надо все бины прятать в конфиги и через конфиги получать к бинам доступ. А потом кто-то жалуется на невозможность зарезолвить циклические зависимости и тратит по неделе на фикс простейшего бага.