Properties and PropertySources in Spring

Introduction

This is a series and it would make a lot of sense if read in a sequence. You can find all the posts under the heading “Spring Beginners to Professionals“. All the modern enterprise level applications require external properties files and it is important to have a clean mechanism of using these properties in the application. Spring provides an abstraction for achieving the same in form of Properties and PropertySources.

This post is a continuation to the ApplicationContext chapter. Remember, this is one of the important features imparted by the ApplicationContext?

How are Properties Used in Applications

One of the most important ways to impart flexibility to an enterprise application is by using external properties. Imagine a scenario where all the required values are hard coded in the source and you have built and deployed the application. Everything works fine until one day, you need to change one of these values.

In such a scenario, you can change the value in the code, re build and deploy your application or you can be smarter and export all these required values into an external properties file and use placeholders in the code.

The next time you need to change anything, just change in the properties file and restart your application server.

What are the ways of supplying external properties to an application?

Few of the practices are to supply it through the System properties, or the Environment properties and through properties files. These properties files can be stored anywhere and can be referenced through a valid URL.

Properties and PropertySources in Spring

Spring provides a PropertySource object which represents a source of name value property pairs. Each such source is identified by a name. The underlying source object for a given PropertySource can be of any valid property encapsulation including java.util.Properties, java.util.Map, ServletContext, ServletConfig etc.

JNDIPropertySource

Spring provides few implementations of the PropertySource out of the box. For e.g.; If you want to read JNDI properties using Spring, you have at your disposal a JNDIPropertySource. If you have ever used plain JNDI it offers API to perform lookups for objects given a name.

Hence, this can work as a PropertySource. The only limitation being, it cannot enumerate all the objects stored in this property source due to the nature of JNDI. It doesn’t allow you to list all the names bound to a context and all its subcontexts. It in fact offers you a lookup feature to query by name.

CommandLinePropertySource

There are other good implementations of the PropertySource which are enumerable. You can query for the complete list of name-value pair within them and this is considered to be efficient. For e.g.: The CommandLinePropertySource exposes all the arguments passed to a Java program including the option(denoted by – or –) arguments.

CompositePropertySource

Another good implementation is CompositePropertySource that can iterate over a set of one or more PropertySource instances which share the same name. Yes it is possible when you supply comma separated list of property file URLs.

Few more PropertySources

  • The MapPropertySource reads the properties from a Java Map object,
  • The PropertiesPropertySource reads it from the Java Properties objects.
  • The ResourcePropertySource reads it from a valid resource or resource location (a valid URL).
  • The SystemEnvironmentPropertySource is a much richer version of MapPropertySource designed to work with environment variables. Compensates for Bash and other shells where a period is not allowed in the property names. They are specifically changed to underscore.

How to tell Spring about a custom PropertySource?

Spring has its own property sources, which we will discuss while discussing the Environment abstraction in the next post. However, if you want few more custom properties to be available in the application at runtime, you need the following:

  • Create a properties file and add all the properties your application would need
  • Tell Spring about the new Property Source.

You can inform Spring about this new source as below:

Annotation driven Configuration

In annotation driven configurations, we tell Spring by annotating the configuration class with the @PropertySource annotation. The name is a user friendly name for the property source. The value is a set of locations where one or more properties files are stored and there key-value pairs will be a part of myPropertySource.

In case, we don’t explicitly give a name, the framework will define a name for this property source.

XML Driven Configuration

In XML configuration, Spring allows you to configure a more complex object called PropertySourcesPlaceholderConfigurer. This is useful when you want to use placeholders for properties. For example, consider our below properties file:

A placeholder for the first property would be  ${mynewpropkey} . Hence, this object allows us to access the property values using placeholders in Spring XMLs as well as Java classes.

Here is a working example.

Above is the Spring configuration XML. The configuration defines a bean named newBean, and its property is populated using a placeholder ${mynewpropkey}. Also, we define the PropertySourcesPlaceholderConfigurer, which takes a location of the properties file and makes Spring aware of it.

And, here is how you can run this sample:

To access the properties in a Java class, you can use the @Value annotation like below:

In this case, Spring will read the value of the property and populate it in the prop variable.

Summary

In this post, we were able to understand the basics of configuring a PropertySource and access the properties in the application. Both using

This post describes PropertySources and Properties in brief but there is a lot to it. We will discuss as and when required. Next, we will learn about the Environment abstraction which is closely related to the PropertySources.

Stay Connected.