loading properties file in spring

Question

One of our team has implemented loading properties this way (see pseudo code below) and advises this approach is right as the client application using this is free to keep t

Answer 1

+1 for Dave's suggestion. You should be using PropertyPlaceholderConfigurer for loading\reading properties. Here is the example i just pulled out from my previous project if you wonder how to use this. This example is for loading multiple properties files but the concept is same. Good luck.

<bean id="projectProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
    <property name="locations">
        <list>
            <value>classpath:config.properties</value>
        </list>
    </property>
</bean>

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="properties" ref="projectProperties" />
</bean>

<bean id="uniqueAssetIdRetriever" class="com.mypackage.Myclass">
    <property name="xml" value="${com.myapp.myproperty1}" />
</bean>

Answer 2

You can put the properties in any file and still use PropertyPlaceholderConfigurer. Here's an example that satisfies both your coworker's concerns and your desire for environment specific stuff:

<bean id="propertyPlaceholderConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
        <list>
            <!-- default settings -->
            <value>classpath:MyCompany.properties</value>
            <!-- environment-specific settings -->
            <value>classpath:MyCompany.${mycompany.env:dev}.properties</value>
            <!-- keep your coworker happy -->
            <value>classpath:${mycoworker}</value>
            <!-- allows emergency reconfiguration via the local file system -->
            <value>file:///${user.home}/MyCompany.properties</value>
        </list>
    </property>
    <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE"/>
    <property name="ignoreResourceNotFound" value="true" />
    <!-- should be validated separately, in case users of the library load additional properties -->
    <property name="ignoreUnresolvablePlaceholders" value="false"/> 
</bean>

If you pass in no -D arguments, then you'll pick up the following properties files, where properties in the later files overwrite previously determined values.

1. MyCompany.properties off the classpath
2. MyCompany.dev.properties off the classpath
3. $HOME/MyCompany.properties if it exists

To swap in a production config for #2, just pass -Dmycompany.env=prod to java. Similarly your coworker can pass -Dmycoworker=/some/path/config.properties if he/she wants.

Answer 3

I'm not sure why a PropertyPlaceholderConfigurator wouldn't have been the correct choice.

I've almost always handled environment-specific configs via a customized PPC that can either (a) get a -D parameter on startup, and/or (b) use the machine name, to decide which property file to load.

For me, this is more convenient than bundling the information in via Maven, since I can more easily test arbitrary configurations from whatever machine I'm on (using a -D property).