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 the properties in any file. Contrary to the widely used propertyplaceholderconfigurer.

application-context.xml

<bean class="com.mypackage.Myclass">
<property name="xml" value="classpath:"{com.myapp.myproperty1}"> </property> 
</bean>

config.properties

com.myapp.myproperty1=data.xml

edit: I should have added it is data.properties and not data.xml. We want to load a property file (this property file is given in the config.properties as a "property". com.myapp.myproperty1=data.properties

java class

import org.springframework.core.io.Resource;
public class Myclass {

private Resource xmlField;

// setter & getter methods..

}

Is it right to use spring core.io.Resource?

Another reason is the client application wants to load a environment specific configuration. I suggested use the propertyconfigurer and use maven profiles to generate the environment specific build

Can you please advise which one suits which case? and if it differs in different scenarios, please help me point out them?

thanks

Answer 1

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 2

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).