Adding Properties to Restful Service, Part I

The Configuration Problem

Every project needs a way to manage configuration. Things like database connections, security, web servers, and application-specific configuration all have settings that can vary from environment to environment.

A primary requirement is to store configuration information externally. If you hard coded database credentials in your source code, obviously it would be very easy to set the configuration in your code and to run the application on that one database, but very difficult to run anywhere else (like, say, production). Not to mention credentials in source code is a security nightmare!


One way that Java has accomplished externalized configuration was with JNDI. I have seen enterprise-scale systems use JNDI to store database credentials. This allowed us to deploy a web application to different environments (dev, qa, prod…) and have it connect to different databases. This certainly works, and is part of the Java standard, but is very heavyweight. It’s another technology to learn, requiring special tools to manage. And the trend in Java these days is towards lighter-weight solutions

Properties Files!

What could be lighter weight than your humble properties file?

Properties files have been with us for a long time, but every project has their own way to find them and insert them into a program. I’ve seen legacy systems with their own custom property management framework, similarly to Spring’s properties framework. The main difference between them is that the custom framework is maintained by the company’s developers (with limited time of course) and the spring community which is continuously maintaining it. Spring Boot provides a nice way to add configuration via properties to a project, let’s take a look at that.

See the Externalized Configuration section in the spring boot docs. To quote:

A SpringApplication will load properties from in the root of your classpath and add them to the Spring Environment. The actual search path for the files is:
classpath root
current directory
classpath /config package
/config subdir of the current directory.

So simply creating a file called “” and placing it in the correct place will the properties in the file immediately and predictably available to your application. That’s what I call convention over configuration!

The Spring Boot Actuator docs section Externalized Configuration goes into more detail. To actually use a property in your code you can inject it into your object using the @Value annotation. Note that this requires a setter on that property.

For instance, this applies the “service.message” property from your

private String value;

My preferred technique would be to inject the values in the constructor. Since property values are usually immutable, I’d rather not have setters for them.

private String message;
public MessageServiceConstructor(@Value("${service.message}") String message) {
   this.message = message;

Additionally, any properties can be overridden with command line arguments directly. For example, you might override the service.message property when running the jar like so:

java -jar build/libs/my-application-1.0.jar --service.message=9999


Externalizing configuration is an important part of every application. Spring Boot provides facilities for easily collecting properties from a properties file or other places in your system, and getting them into your application. Next time we’ll look at other exciting ways to deal with configuration!


Leave a comment

Filed under Software Engineering

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s