开发者

PropertyPlaceholderConfigurer vs Filters -- Spring Beans

开发者 https://www.devze.com 2022-12-28 18:40 出处:网络
I\'ve got a question regarding the difference between PropertyPlaceholderConfigurer (org.springframework.beans.factory.config.PropertyPlaceholderConfigurer) and normal filters defined in my pom.xml.

I've got a question regarding the difference between PropertyPlaceholderConfigurer (org.springframework.beans.factory.config.PropertyPlaceholderConfigurer) and normal filters defined in my pom.xml.

I've been looking at examples, and it seems that even though filters are defined and marked to be active by default in the pom.xml they still make use of PropertyPlaceholderConfigurer in Spring's applicationContext.xml.

This means that the pom.xml has a reference to a filter-LOCAL.properties while applicationContext.xml has a reference to application.properties and they both contain the same settings.

Why is that? Is that how it is supposed to be done? I'm able to run the goal mvn jetty:run without the application.properties present, but if I add settings to the application.properties that differ from the filter-LOCAL.properties they don't seem to override.

Here's an example of what I mean:

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}"开发者_StackOverflow中文版/>
        <property name="username" value="${jdbc.username}"/>
        <property name="password" value="${jdbc.password}"/>
    </bean>

an example of the content of application.properties and filters-LOCAL.properties

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

Can I remove the propertyConfigurer from the applicationContext, create a PROD filter and disregard the application.properties file, or will that give me issues when deploying to the production server?


You should rather use Maven to select which Spring properties file to use depending on which environment you're building for.

When you're testing in your IDE, you should just start the Spring container from the test without using Maven for anything else than managing your dependencies.


For the record, here is what the author of the blog series the OP is following wrote in this comment:

I used to be a big fan of Spring’s PropertyPlaceholderConfigurer but ever since I started using maven I don’t find it as useful as maven’s filters, using either a filters file as explained here, or by having multiple profiles in the pom for the different deployment layers with each profile specifying the properties.

The biggest gripe I have with the PropertyPlaceholderConfigurer is that you can only have one PropertyPlaceholderConfigurer bean. And it’s not well documented.

With maven’s filter files you can have as many as you like.

The other reason I prefer maven’s filters is that with them you can do a ‘mvn package’ and then poke around in the target directory and eyeball the filtered config files and see what it did. With Spring’s PropertyPlaceholderConfigurer you don’t find out what’s been substituted until the app is started.

I second this opinion and prefer the filter approach over using the PropertyPlaceholderConfigurer and the Antrun plugin to copy say test.properties into application.properties when running my tests. And using filtered resources is well supported by all major IDEs (Eclipse, IntelliJ, NetBeans) so I don't see why I should not use it.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号