Странная логика выбора файла свойств для приложения с весенней загрузкой

Я работаю над многомодульным проектом Maven, где каждый модуль представляет собой приложение весенней загрузки (т.е. упаковано в виде исполняемого файла jar). Некоторые модули зависят от других. В проекте используется platform-bom версии 1.1.4.RELEASE.

Я обнаружил то, что считаю странной логикой для принятия решения, какие файлы свойств приложения использовать - хотя это явно не противоречит информации на https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html, в лучшем случае он все еще кажется неинтуитивным.

Ситуация была обнаружена при следующем стечении обстоятельств:

  1. Модуль A имеет файл application.properties в своей папке ресурсов, поэтому он упакован в корень загрузочного jar-файла Spring. Этот application.properties определяет стандартный источник данных Spring JPA.

  2. Модуль B зависит от A, но имеет в нем свой собственный файл свойств application.yml (а также файл .properties для конкретного профиля, например application-foo.properties). В этом файле нет записей для источника данных JPA, но код ожидает, что источник данных будет внедрен.

Неожиданно оказалось, что application.properties из A считываются, когда тесты B выполняются в сборке Maven, и используются для настройки источника данных, используемого B. Из приведенной выше ссылки можно сделать вывод, что это правильное поведение ("путь к классам root "в 24.3 может означать в корне jar в пути к классам, который будет jar A при запуске тестов для B). NB, свойства .yml также обрабатываются.

Однако, если я предоставлю пустой application.properties в ресурсах B вместе с файлом .yml, кажется, что это будет иметь приоритет во время тестов, и application.properties из A больше не будет обрабатываться вообще. Файл .yml все еще обрабатывается.

Из документации я бы подумал, что все подходящие файлы свойств должны быть обработаны, т.е. если A application.properties читается, то это все равно должно быть, если B предоставляет свой собственный файл (с приоритетом B). Также кажется, что файлы .properties и .yml не обрабатываются одинаково (существование application.yml не препятствовало чтению application.properties A, но наличие application.properties в B помешало).

Пожалуйста, не мог бы кто-нибудь прояснить, что такое ожидаемое поведение, и прокомментировать, правильна ли документация (ссылка выше)? Особенно:

1) Если в документации указано, что файлы свойств могут быть загружены из «корня пути к классам», должен ли он также включать корень любых jar-файлов в пути к классам?

2) Должно ли предоставление application.properties в B останавливать обнаружение A?

3) Следует ли по-другому рассматривать свойства .yml в связи с этим поведением?


spring-boot properties-file classpath
person Gary Sedgwick    schedule 18.12.2015    source источник
comment
Таким образом, читается только application.properties B. Вы должны создать a.properties в проекте A. И в классе A @Configuration вы будете использовать @PropertySource("classpath:/a.properties")   -  person Thang Hoang    schedule 18.12.2015

Ответы (1)


arrow_upward
1
arrow_downward

Корень пути к классам - это просто плоское представление всех файлов во всех содержащихся в нем архивах. Вы можете рассматривать это как разархивирование чего-либо в каталоге, а затем его чтение (физически это другое, но сравнимо с тем, что происходит при чтении файлов). Ближайшие к вам файлы будут прочитаны раньше любых других файлов. Следовательно, когда вы предоставляете свой собственный application.properties, который переопределяет те, которые включены в файлы jar.

Так что да, это остановит чтение файлов, отправленных в банках. Зачем хорошо представлять себе 20 банок, каждая из которых содержит application.properties, как можно гарантировать заказ, какой из них должен выиграть? Особенно, если они содержат перекрывающиеся свойства. Так что будет прочитана только одна.

.properties и .yml - это разные файлы, и поэтому оба они читаются (я даже считаю, что .properties читаются перед .yml файлами, но не уверен). Так что да, это тоже ожидаемое поведение.

person M. Deinum    schedule 18.12.2015