Spring 3.1 PropertySourcesPlaceholderConfigurer и условный импорт

Глядя на новую поддержку свойств spring в 3.1 (http://blog.springsource.org/2011/02/15/spring-3-1-m1-unified-property-management/), похоже, что это должно быть возможно:

<context:property-placeholder location="/WEB-INF/application-customer-dev.properties,classpath:application-customer.properties" ignore-resource-not-found="true"/>

<import resource="classpath*:com/x/core/security/security-${login.security}.xml"/>

где login.security находится в application-customer-dev.properties как:

login.security=dev

(и security-dev.xml существует в соответствующем месте). Я пропускаю что-то, хотя, поскольку login.security не может быть разрешен. Я ожидал бы такого поведения в версиях spring до 3.1, но похоже, что это должно быть верно с 3.1 (который мы используем)?

ОТВЕТЫ

Ответ 1

Сноска [2] вашей ссылки:

[2]: Поскольку обработка элементов <import/> обязательно возникает перед вызовом BeanFactoryPostProcessors, что означает, что даже PropertyPlaceholderConfigurer не мог помочь здесь. Поскольку среда и ее набор PropertySources настроены до обновления контейнера, заполнители элементов могут быть разрешены в отношении среды без каких-либо проблем с жизненным циклом.

UPDATE

В соответствии с javadoc для PropertySourcesPlaceholderConfigurer PropertySourcesPlaceholderConfigurer - это BeanFactoryPostProcessor, поэтому в сноске действительно говорится, что импорт разрешен перед установкой PropertySourcesPlaceholderConfigurer, поэтому он не будет работать либо (фактически, в момент разрешения <import/> конфигуратор может даже не существовать!) Да, когда он будет установлен, он будет посмотрите Environment, но вы не можете использовать его для решения внутри <import/>, потому что в это время никакие постпроцессоры не работают. И это включает PropertySourcesPlaceholderConfigurer.

В основном Spring Настройка контекста XML выглядит примерно так:

  • Контекст создан.
  • Environment.
  • XML читается (все XML, при необходимости разрешая импорт). Bean.
  • BeanFactoryPostProcessor устанавливаются и вызывается, обрабатывая определения Bean.
  • BeanPostProcessor.
  • Beans создаются в соответствии с определениями Bean. Используются BeanPostProcessors.

Это аналогичная проблема, которая приводит к тому, что вы не можете использовать свойство order для многих постпроцессоров для применения BeanPostProccesor до BeanFactoryPostProcessor (чтобы сделать что-то вроде make PropertyPlaceholderConfigurer place placeholders из @PersistenceContext): поведение жестко закодировано в контексте приложения Spring, поэтому вам придется обойти его, специализируясь на некоторых классах Spring.

Ответ 2

Я думаю, что вы неправильно читаете блог немного @Kurt. Он должен быть разрешен, если источник свойств, содержащий свойство, присутствует до того, как начинают создаваться определения bean.

Таким образом, способ разрешить импорт будет осуществляться двумя способами: 1. установите переменную среды с этим параметром (-Dlogin.security=dev), который по умолчанию будет зарегистрирован как источник свойства

2. Зарегистрировать файл как источник ресурса программно, упомянутый в статье в блоге, написав собственный ApplicationContextInitializer, чтобы зарегистрировать ваш источник собственности - вы должны иметь возможность использовать ResourcePropertySource, чтобы зарегистрировать исходный ресурс на основе файла

Ответ 3

Теперь вам будет намного проще, чем вам нужно @Inject Environment и использовать профили. Вам не нужно заменять часть имени файла.