Мне любопытно, что является лучшим методом для специфических свойств среды (или даже сервера) для зависимостей.
Это не для свойств, которые управляются applicationContext, так как я знаю о {env}Соглашение -application.properties, которое поддерживает Spring.
Я приведу небольшой пример, чтобы уточнить:
Мой проект - это проект A. В A мы зависим от проекта B
Pom.xml
<dependency>
<groupId>com.B</groupId>
<artifactId>B</artifactId>
</dependency>
Артефакт B зависит от свойств B., которые он не предоставляет, и он должен находиться в пути к классам.Я не могу выполнить рефакторинг Artifact B.
Содержимое B.properties:
b.someproperty=${property.placeholder}/b/dir
Содержимое application.properties :
property.placeholder=default
Содержимое dev-application.properties:
property.placeholder=dev
Поэтому, когда я запускаю мое приложение весенней загрузки с параметром -Dspring.profiles.active = dev, b.someproperty должен преобразовываться в dev / b / dir
Что у меня естьдо сих пор пытался (это работало):
1) Внешние свойства, которые находятся на сервере, с заполнителями уже разрешаются и просто добавляются в путь к классам во время выполнения (поэтому у каждого сервера будет свой собственный файл B.propertiesбез заполнителей, и это не будет частью процесса сборки / развертывания)
2) Класс в загрузочном фляге spring, который принимает свойства в b.properties, разрешает все заполнители и записывает его вфайл на сервере, а затем добавляет этот файл в classpath.Поэтому запуск приложения с параметром -Dspring.profiles.active = dev приведет к созданию на сервере b.properties без заполнителей, и все будет содержаться внутри jar.
Ни одно из этих решений не является ни чистым, ни хорошим (имо).Можно ли разрешить заполнители при использовании свойств, даже если они не управляются контекстом приложения?
Любое понимание или критика моих текущих решений приветствуются.