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 предоставляет ряд методов, позволяющих точно управлять набором источников свойств.


Читайте также:


Комментарии

Популярные сообщения из этого блога

Методы класса Object в Java

Как получить текущий timestamp в Java

Основные опции JVM для повышения производительности и отладки