Проблема переопределения свойств приложения в приложении Spring -boot (для профиля), запущенном с помощью свойстваLauncher - SOLVED

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

У меня есть автоматически сконфигурированное приложение Spring -boot (т.е. с помощью @EnableAutoconfiguration), которое имеет несколько профилей, которые я запускаю с использованием PropertiesLauncher, а не JarLauncher (причина связана с ограничениями развертывания - Мне нужно развернуть взорванный каталог, а не архив, в файловую систему только для чтения.)

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

application-dev.properties
application-qa.properties
application-prd.properties

И пусть, скажем, ради аргумента, что application-dev.properties содержит:

foo.bar=baz
foo.baz=other

Для любой среды может потребоваться переопределить существующее свойство, а также указать отсутствующий (например, производственный пароль), и проблема, которую я вижу, связана с переопределяющими свойствами, уже объявленными в application-${profile}.properties на пути к классам. (Поставлять свойства, отсутствующие в файле classpath, отлично, это не проблема.)

Скажем, у меня есть файл свойств переопределений в местоположении файловой системы, например:

/local/appname/dev/overrides/application.properties

и я хочу переопределить свойство foo.bar, а также объявить новое свойство foo.password.

Поэтому содержимое файла переопределений:

foo.bar=overridden-value
foo.password=something

Когда я запускаю приложение, я использую командную строку примерно так:

java -Dspring.config.location=file:/local/appname/dev/overrides/ 
     -Dspring.profiles.active=dev 
     org.springframework.boot.loader.PropertiesLauncher 
     --debug &

Проблема, которую я вижу, заключается в том, что, хотя foo.password, свойство не, объявленное в application-dev.properties файле , выбрано, переопределение foo.bar игнорируется - я все еще вижу значение baz от application-dev.properties, а не значение, overridden-value от /local/appname/dev/overrides/application.properties.

При включенной опции --debug я могу видеть, что журнал ConfigFileApplicationListener загрузил как файл переопределений (из файловой системы), так и файл профиля (из пути к классам), в этом порядке.

Я соблазняю, возможно, наивный вывод о том, что, поскольку файл переопределения указан первым, он загружается сначала, а затем переопределяется файлом определенного профиля по умолчанию из пути к классам, который указан ниже. Однако я понимаю, что порядок перечисления в журнале не обязательно коррелирует с поведением. И я попытался изменить порядок путей, объявленных в свойстве spring.config.location, так что classpath: указан до file:..., но это не помогло, и я не уверен, что это все равно, учитывая, что Spring -boot ясно указывает, что местоположения свойств по умолчанию всегда ищутся, даже если вы указали значение для spring.config.location.

Документация Spring -boot очень специфична в отношении порядка, который свойства разрешены для исполняемого JAR файла Spring -boot, в порядке убывания приоритета:

  • Аргументы командной строки.
  • Свойства системы Java (System.getProperties()).
  • Переменные среды ОС.
  • Атрибуты JNDI из java:comp/env
  • A RandomValuePropertySource, который имеет свойства только в random.*.
  • Свойства приложения вне вашей упакованной банки (application.properties включая варианты YAML и профиля).
  • Свойства приложения упакованы внутри вашей банке (application.properties включая варианты YAML и профиля).
  • @PropertySource аннотации в классах @Configuration.
  • Свойства по умолчанию (заданы с помощью SpringApplication.setDefaultProperties).

Обратите внимание на строки 6 и 7 - свойства вне по свойствам внутри вашей банке.

То, что не указано, насколько я могу видеть, и которое может быть источником моей путаницы/проблемы, происходит, когда вы не, используя JAR, но взорванный каталог (и поэтому PropertiesLauncher.)

Если поведение взорванного каталога соответствовало тому, что указано для JAR, я бы ожидал, что значения свойств, объявленных в /local/appname/dev/overrides/application.properties, переопределит одно и то же имя, объявленное в classpath:application-dev.properties, но это не означает, t, похоже, имеет место.

Также отмечено в документации Spring -boot (приложение C.4 на PropertiesLauncher) упоминается свойство loader.home, которое описывается как "... [] Местоположение дополнительного файла свойств, например. /opt/app (по умолчанию - ${user.dir}) '.

Поэтому я попытался использовать loader.home вместо spring.config.location, но безрезультатно.

(Обновление: я также попытался использовать loader.config.location, и у меня есть две заметки: кажется, нужен файл, а не каталог (поэтому его поведение не аналогично spring.config.location) и когда я задал путь к файлу, а не родительский каталог, он все равно не помог.)

Может ли кто-нибудь определить, что я делаю неправильно, или какие неправильные предположения (я) делаю?

Ответы

Ответ 1

Спасибо, Дейв, ваше предложение было на 100% правильным.

Если я переименую файл свойств в /local/appname/dev/overrides в application-dev.properties, тогда значения свойств из этого файла do переопределяют те, что указаны в classpath:application-dev.properties.

Я был уверен, что вчера попробовал эту комбинацию, но я думаю, что, должно быть, это остановило работу, когда я играл с указанием spring.config.location и получил это неправильно, поэтому он не искал файл переопределения в правильное место.