Spring IoC контейнер: абстракция Environment, PropertySource
Абстракция Spring Environment предоставляет операции поиска по настраиваемой иерархии источников свойств. Рассмотрим следующий список:
Java
ApplicationContext ctx = new GenericApplicationContext();
Environment env = ctx.getEnvironment();
boolean containsMyProperty = env.containsProperty("my-property");
System.out.println("Содержит ли мое окружение свойство 'my-property'? " + containsMyProperty);
Kotlin
val ctx = GenericApplicationContext()
val env = ctx.environment
val containsMyProperty = env.containsProperty("my-property")
println("Содержит ли мое окружение свойство 'my-property'? $containsMyProperty")
В предыдущем фрагменте мы видим высокоуровневый способ спросить Spring, определено ли свойство my-property для текущей среды. Чтобы ответить на этот вопрос, объект Environment выполняет поиск по набору объектов PropertySource. PropertySource - это простая абстракция над любым источником пар ключ-значение, а стандартная среда Spring настроена с двумя объектами PropertySource: один представляет набор системных свойств JVM (System.getProperties()), а другой представляет набор переменных системной среды (System.getenv()).
Эти источники свойств по умолчанию присутствуют для StandardEnvironment для использования в автономных приложениях. StandardServletEnvironment заполняется дополнительными источниками свойств по умолчанию, включая конфигурацию сервлета и параметры контекста сервлета. При желании он может включить JndiPropertySource.
Конкретно, когда вы используете StandardEnvironment, вызов env.containsProperty("my-property") возвращает true, если системное свойство my-property или переменная среды my-property присутствует во время выполнения.
Выполняемый поиск является иерархическим. По умолчанию системные свойства имеют приоритет над переменными среды. Итак, если свойство my-property установлено в обоих местах во время вызова env.getProperty("my-property"), значение системного свойства "выигрывает" и возвращается. Обратите внимание, что значения свойств не объединяются, а полностью переопределяются предыдущей записью.
Для обычного StandardServletEnvironment полная иерархия выглядит следующим образом, с записями с наивысшим приоритетом вверху:
- Параметры ServletConfig (если применимо - например, в случае контекста DispatcherServlet)
- Параметры ServletContext (записи context-param web.xml)
- Переменные среды JNDI (java:comp/env/ записи)
- Свойства системы JVM (аргументы командной строки -D)
- Системная среда JVM (переменные среды операционной системы)
Самое главное, что весь механизм настраивается. Возможно, у вас есть собственный источник свойств, который вы хотите интегрировать в этот поиск. Для этого реализуйте и создайте собственный PropertySource и добавьте его в набор PropertySources для текущей среды. В следующем примере показано, как это сделать:
Java
ConfigurableApplicationContext ctx = new GenericApplicationContext();
MutablePropertySources sources = ctx.getEnvironment().getPropertySources();
sources.addFirst(new MyPropertySource());
Kotlin
val ctx = GenericApplicationContext()
val sources = ctx.environment.propertySources
sources.addFirst(MyPropertySource())
В предыдущем коде MyPropertySource был добавлен с наивысшим приоритетом в поиске. Если он содержит свойство my-property, свойство обнаруживается и возвращается в пользу любого свойства my-property в любом другом PropertySource. API MutablePropertySources предоставляет ряд методов, позволяющих точно управлять набором источников свойств.
Читайте также:
- Spring IoC контейнер: абстракция Environment, профили определения компонентов, профиль по умолчанию
- Spring IoC контейнер: абстракция Environment, профили определения компонентов, активация профиля
- Spring IoC контейнер: абстракция Environment, профили определения компонентов, использование @Profile
Комментарии
Отправить комментарий