Spring Boot @ConfigurationProperties и коллекции

Дано:

Сервис на spring boot(2.6.4) + kotlin(1.5.31) по выгрузке произвольного количества отчётов по крону. Каждый отчет имеет свои настройки. Для конфигурирования списка свойств отчётов используется собственно список. Для инжекта в приложение используется data class с аннотацией @ConfigurationProperties, где одно из свойств — список data class.

Выглядит это примерно так:

#application.yml report-export:   cron: 0 0 12 * *   reports:     - file-prefix: REPORT1       region-name: Москва       sftp-host: host1       sftp-port: 22       sftp-user: user1       sftp-password: pwd1     - file-prefix: REPORT2       region-name: Подольск       sftp-host: host1       sftp-port: 22       sftp-user: user1       sftp-password: pwd2

@ConfigurationProperties("report-export") @ConstructorBinding data class ReportExportProperties(     val cron: String,     val reports: List<ReportProperties> ) {      data class ReportProperties(         val filePrefix: String,         val regionName: String,         val sftpHost: String,         val sftpPort: Int,         val sftpUser: String     ) }

Оказалось, что это не лучшее решение использовать список, если вы планируете размещать часть свойств его элементов в разных property source. Конкретно в моем случае, секрет sftp-password должен был быть размещен в Vault.

Согласно документации списки для @ConfigurationProperties мёрджутся не так, как для остальных сложенных структур. Если положить в Vault только секреты sftp-password, то остальные свойства data class из списка будут инициализироваться дефолтными свойствами, если они заданы ( если не заданы — контекст не поднимется). Т.е. список не мёрджится, а берется из property source с большим приоритетом как есть.

Ниже тест, показывающий, показывающий, что для вложенных классов и свойств, мёрдж работает, а для списков — нет:

#application.yml tpp:   test:     root:       root-field1: default       nested:         nested-field1: default       nested-list:         - nested-list-field1: default1         - nested-list-field1: default2 #application-dev.yml tpp:   test:     root:       root-field2: dev       nested:         nested-field2: dev       nested-list:         - nested-list-field2: dev1         - nested-list-field2: dev2

@ConfigurationProperties("tpp.test.root") @ConstructorBinding data class RootPropperties(     val rootField1: String = "",     val rootField2: String = "",     val nested: NestedProperties = NestedProperties(),     val nestedList: List<NestedListProperties> = listOf() ) {      data class NestedProperties(         val nestedField1: String = "",         val nestedField2: String = ""     )      data class NestedListProperties(         val nestedListField1: String = "",         val nestedListField2: String = ""     ) }

@ActiveProfiles("dev") @SpringBootTest internal class ConfigurationPropertiesTest {      @Autowired     lateinit var rootPropperties: RootPropperties      @Test     fun `configuration properties binding`() {         assertEquals("default", rootPropperties.rootField1)         assertEquals("dev", rootPropperties.rootField2)          assertEquals("dev", rootPropperties.nested.nestedField2)         assertEquals("default", rootPropperties.nested.nestedField1)          assertTrue(rootPropperties.nestedList.isNotEmpty())         assertEquals("dev1", rootPropperties.nestedList[0].nestedListField2)         assertEquals("dev2", rootPropperties.nestedList[1].nestedListField2)         // Здесь падает         // org.opentest4j.AssertionFailedError:         //Expected :default1         //Actual   :         assertEquals("default1", rootPropperties.nestedList[0].nestedListField1)         // Здесь падает         // org.opentest4j.AssertionFailedError:         //Expected :default2         //Actual   :         assertEquals("default2", rootPropperties.nestedList[1].nestedListField1)     } } 

Интересно, что если переписать тест, запрашивая все значения из Environment, то мы получим корректные значения для всех вложенных структур:

@ActiveProfiles("dev") @SpringBootTest internal class ConfigurationPropertiesTest {      @Autowired     lateinit var environment: Environment      @Test     fun `environment binding`() {         assertEquals("default", environment.getProperty("tpp.test.root.root-field1"))         assertEquals("dev", environment.getProperty("tpp.test.root.root-field2"))          assertEquals("default", environment.getProperty("tpp.test.root.nested.nested-field1"))         assertEquals("dev", environment.getProperty("tpp.test.root.nested.nested-field2"))          assertEquals("default1", environment.getProperty("tpp.test.root.nested-list[0].nested-list-field1"))         assertEquals("dev1", environment.getProperty("tpp.test.root.nested-list[0].nested-list-field2"))          assertEquals("default2", environment.getProperty("tpp.test.root.nested-list[1].nested-list-field1"))         assertEquals("dev2", environment.getProperty("tpp.test.root.nested-list[1].nested-list-field2"))     } }

В ответе на вопрос в моем issue сказано, что так сделано намеренно и каких-либо изменений для списков не планируется. Предложенный workaround — использовать Map вместо коллекций. Ниже приведен пример, как можно переписать предыдущий тест:

#application.yml tpp:   test:     root-map:       root-field1: default       nested:         nested-field1: default       nested-map:         1:           nested-map-field1: default1         2:           nested-map-field1: default2  #application-dev.yml tpp:   test:     root-map:       root-field2: dev       nested:         nested-field2: dev       nested-map:         1:           nested-map-field2: dev1         2:           nested-map-field2: dev2 

@ActiveProfiles("dev") @SpringBootTest internal class ConfigurationPropertiesMapTest {      @Autowired     lateinit var environment: Environment      @Autowired     lateinit var rootPropperties: RootMapPropperties      @Test     fun `configuration properties binding`() {         Assertions.assertEquals("default", rootPropperties.rootField1)         Assertions.assertEquals("dev", rootPropperties.rootField2)          Assertions.assertEquals("default", rootPropperties.nested.nestedField1)         Assertions.assertEquals("dev", rootPropperties.nested.nestedField2)          Assertions.assertTrue(rootPropperties.nestedMap.isNotEmpty())         Assertions.assertEquals("default1", rootPropperties.nestedMap["1"]!!.nestedMapField1)         Assertions.assertEquals("dev1", rootPropperties.nestedMap["1"]!!.nestedMapField2)         Assertions.assertEquals("default2", rootPropperties.nestedMap["2"]!!.nestedMapField1)         Assertions.assertEquals("dev2", rootPropperties.nestedMap["2"]!!.nestedMapField2)     } }

У меня нет однозначного мнения относительно ответа от команды spring, что не планируется пересматривать алгоритм мёрджа для коллекций. С одной стороны понятно, что есть некая неоднозначность относительно того, что делать, если например в одном property source 2 элемента, в другом 3. Как это интерпретировать, мёрджить ли этот список сложением элементов например? Мое мнение, что можно мёрджить элементы списка также, как Map относительно индексов. Т.е. первые 2 элемента мёрджутся согласно приоритетам property source, а 3й полностью берется как есть, т.к. он задан только в одном property source. Как показано выше Environment вполне себе справляется с разрешением этих неоднозначностей. А как думаете Вы?

Это мой первый пробный пост. Надеюсь, он не получился слишком поверхностным.