У нас есть особый формат для наших файлов конфигурации, в котором вместо нескольких файлов - например, dev.properties, uat.properties, prod.properties - все значения хранятся в одном файле, но разделены префиксами для каждой среды. Например:
SERVICE_PORT = 9800
DEV_SERVICE_PORT = 7800
UAT_SERVICE_PORT = 6600
У нас есть существующий класс (подкласс PropertyPlaceholderConfigurer), который просматривает эти значения и решает, какой префикс добавить внутри resolvePlaceHolder () на основе IP-адреса, на котором он выполняется, то есть для определенного диапазона IP-адресов используйте префикс DEV_, для другого, используйте префикс UAT_. Затем эти значения передаются другим bean-компонентам, в некоторых случаях с использованием контекста xml, а в некоторых с использованием аннотации @ Value $ {} для некоторых конструкторов bean-компонентов. Использование префиксов прозрачно, поэтому все остальные конфиги будут использовать SERVICE_PORT (в примере)
Мы хотим изменить это так, чтобы вместо использования IP-адресов мы просто определяли активный профиль Spring. У нас есть настраиваемый ApplicationContextIniitalizer в нашем web.xml, который обнаруживает системное свойство java, которое указывает наш тип среды.
У меня проблема в том, что на момент вызова метода resolvePlaceHolder (), похоже, еще не было никаких активных профилей! Что я делаю, чтобы обнаружить активный профиль:
- создать экземпляр StandardEnvironment
- вызовите getActiveProfiles ()
(2) всегда кажется, что возвращает пустой массив. Это означает, что разрешение замещения свойств происходит до активации каких-либо профилей Spring. Это правильно??
Когда устанавливается активный профиль по отношению к другим событиям во время загрузки контекста Spring, таким как создание bean-компонентов, загрузка файлов свойств и т. Д.?
Можно ли обнаружить активный профиль во время вызова метода resolvePlaceHolder ()? Должен ли я вместо этого расширять другой класс?
