Spring has always tried to be as transparent as possible when it comes to working with properties. Before Spring 3.1 however, the mechanism of both adding new sources of properties into Spring as well as actually using the properties wasn’t as flexible and as robust as it could be.

Starting with Spring 3.1, the new Environment and PropertySource abstractions simplify working with properties. The default Spring Environment now contains two property sources: the System properties and the JVM properties, with the System properties having precedence.

For more information on the unified property management in Spring 3.1, see this official article.

Registering Properties via the XML namespace

In an XML configuration, new property files can be made accessible to Spring via the following namespace element:

Registering Properties via Java Annotations

Spring 3.1 also introduces the new @PropertySource annotation, as a convenient mechanism of adding property sources to the environment. This annotation is to be used in conjunction with Java based configuration and the @Configuration annotation:

As opposed to using XML namespace element, the Java @PropertySource annotation does not automatically register a PropertySourcesPlaceholderConfigurer with Spring. Instead, the bean must be explicitly defined in the configuration to get the property resolution mechanism working. The reasoning behind this unexpected behavior is by design and documented on this issue.

Behind the Scenes – the Spring Configuration

Before Spring 3.1

Since the convenience of defining property sources with annotations was introduced in the recently released Spring 3.1, XML based configuration was necessary in the previous versions.

Defining a <context:property-placeholder> XML element automatically registers a new PropertyPlaceholderConfigurer bean in the Spring Context. This is also the case in Spring 3.1 if, for backwards compatibility purposes, the XSD schemas are not updated to the 3.1 versions.

In Spring 3.1

From Spring 3.1 onward, the XML <context:property-placeholder> will no longer register the old PropertyPlaceholderConfigurer but the newly introduced PropertySourcesPlaceholderConfigurer. This replacement class was created be more flexible and to better interact with the newly introduced Environment and PropertySource mechanism; it should be considered the standard for 3.1 applications.

Properties by hand in Spring 3.0 – PropertyPlaceholderConfigurer

Besides the convenient methods of getting properties into Spring – annotations and the XML namespace – the property configuration bean can also be defined and registered manually. Working with the PropertyPlaceholderConfigurer gives us full control over the configuration, with the downside of being more verbose and most of the time, unnecessary.

Java configuration

XML configuration

Properties by hand in Spring 3.1 – PropertySourcesPlaceholderConfigurer

Similarly, in Spring 3.1, the new PropertySourcesPlaceholderConfigurer can also be configured manually:

Java configuration

XML configuration

Using properties in Spring

Both the older PropertyPlaceholderConfigurer and the new PropertySourcesPlaceholderConfigurer added in Spring 3.1 resolve ${…} placeholders within bean definition property values and @Value annotations.

For example, to inject a property using the @Value annotation:

Using properties in Spring XML configuration:

And lastly, obtaining properties via the new Environment APIs:

Properties Search Precedence

By default, in Spring 3.1, local properties are search last, after all environment property sources, including property files. This behavior can be overridden via the localOverride property of the PropertySourcesPlaceholderConfigurer, which can be set to true to allow local properties to override file properties.

In Spring 3.0 and before, the old PropertyPlaceholderConfigurer also attempted to look for properties both in the manually defined sources as well as in the System properties. The lookup precedence was also customizable via the systemPropertiesMode property of the configurer:

• never – Never check system properties
• fallback (default) – Check system properties if not resolvable in the specified properties files
• override – Check system properties first, before trying the specified properties files. This allows system properties to override any other property source.

Conclusion

This article covered the various ways to work with Properties in Spring, discussing both the older Spring 3.0 and below and the new support for properties, introduced in Spring 3.1. For a project making heavy use of properties, check out the github project.

If you read this far, you should follow me on twitter here.