PropertyPlaceholderConfigurer vs Filters - Spring Beans

У меня возник вопрос о различии между PropertyPlaceholderConfigurer (org.springframework.beans.factory.config.PropertyPlaceholderConfigurer) и нормальными фильтрами, определенными в моем pom.xml.PropertyPlaceholderConfigurer vs Filters - Spring Beans

Я смотрел примеры, и кажется, что, хотя фильтры определены и отмечены как активные по умолчанию в pom.xml, они все еще используют PropertyPlaceholderConfigurer в приложении SpringContext.xml Spring.

Это означает, что pom.xml ссылается на filter-LOCAL.properties, а applicationContext.xml ссылается на application.properties, и оба они содержат одинаковые настройки.

Почему? Это то, как это должно быть сделано? Я могу запустить цель mvn jetty: запускать без приложения application.properties, но если я добавлю настройки к свойствам application.properties, которые отличаются от filter-LOCAL.properties, они, похоже, не переопределяют.

Вот пример того, что я имею в виду:

pom.xml

 
    <profiles> 
     <profile> 
      <id>LOCAL 
      <activation> 
       <activeByDefault>true 
      </activation> 
      <properties> 
       <env>LOCAL 
      </properties> 
     </profile> 
    </profiles>

applicationContext.xml

 
    <bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
     <property name="locations"> 
      <list> 
       <value>classpath:application.properties 
      </list> 
     </property> 
     <property name="ignoreResourceNotFound" value="true"/> 
    </bean> 

    <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> 
     <property name="driverClassName" value="${jdbc.driver}"/> 
     <property name="url" value="${jdbc.url}"/> 
     <property name="username" value="${jdbc.username}"/> 
     <property name="password" value="${jdbc.password}"/> 
    </bean>

пример содержания application.properties и фильтры -LOCAL.properties

 
jdbc.driver=org.postgresql.Driver 
jdbc.url=jdbc:postgresql://localhost/shoutbox_dev 
jdbc.username=tester 
jdbc.password=tester

Могу ли я удалить propertyConfigurer из ApplicationContext, создать PROD фильтр и игнорировать файл application.properties, или которые дают мне выдает при развертывании на сервере?

источник

2010-05-03 John

Вы должны использовать Maven для выбора файла свойств Spring, который будет использоваться в зависимости от среды, для которой вы строите.

Когда вы тестируете в своей среде IDE, вы должны просто запустить контейнер Spring из теста, не используя Maven для чего-либо другого, кроме управления вашими зависимостями.

источник

2010-05-03 11:42:51 Espen

У вас есть предложение, чтобы узнать, как использовать Maven для выбора свойств пружины, как вы предложили? – John

@John: Лично я предпочитаю плющ и муравей, но принципы должны быть одинаковыми. В зависимости от того, для какой среды я создаю, я копирую другой файл свойств и переименовываю его, например, в application.properties. Тогда контекст приложения Spring, который импортирует PropertyPlaceholderConfigurer, знает только о application.properties. Если это скопировано из test.properties или production.properties, не указано для контейнера Spring. Только мои тестовые контексты знают о свойствах теста для моих тестов JUnit. – Espen

-1 - создание отдельных экземпляров вашего развертывания для каждой среды - плохая идея. Он не масштабируется хорошо, и вам в конечном итоге придется взломать открытую войну, чтобы увидеть, какие свойства включены. См. Мой ответ здесь для альтернативного подхода: http://stackoverflow.com/questions/1311360/property-placeholder-location-from-another-property/1312341#1312341 – Pablojim

Для записи, здесь является то, что автор серии блог ФП следующим писал в this comment:

Раньше я большой поклонник весна PropertyPlaceholderConfigurer но никогда с тех пор как я начал использовать Maven Я не считаю полезным в качестве фильтров в Maven, используя либо файл фильтры, как описано здесь, или при наличии множественного профилей в П для различных слоев развертывания с каждым профилем с указанием свойств.

Самый большой тиски, я с PropertyPlaceholderConfigurer что вы можете иметь только один PropertyPlaceholderConfigurer боб. И это плохо документировано.

С файлами фильтра maven вы можете иметь столько, сколько хотите.

Другая причина я предпочитаю фильтры Maven является то, что с ними можно сделать «МВН пакет», а затем копаться в целевой каталог и глазное яблоко отфильтрованные файлы конфигурации и посмотреть, что он сделал. С весны PropertyPlaceholderConfigurer вы не узнаете, что было заменено , пока приложение не запущено.

Я второй это мнение и предпочитают подход фильтра по сравнению с использованием PropertyPlaceholderConfigurer и плагин Antrun скопировать сказать test.properties в application.properties при выполнении моих тестов. И использование фильтрованных ресурсов хорошо поддерживается всеми основными IDE (Eclipse, IntelliJ, NetBeans), поэтому я не понимаю, почему я не должен его использовать.

источник

2010-05-04 19:02:17

Я предпочитаю использовать элемент Spring , поскольку я не являюсь огромным поклонником глобальных свойств. – Espen

PropertyPlaceholderConfigurer vs Filters - Spring Beans

ответ

Смежные вопросы