Spring Boot External Configuration

By Daniel Vladimirov / a few months ago

Spring Boot offers a variety of ways for you to externalize the application configuration, so that you can run your service in different environments and with different setup. The most popular configuration options are: property files and YAML files. There’s also the option to pass command line properties as well as to use environment variables. Properties are then made available for injection through the @Value annotation or they can be deserialized into classes.


Spring Boot

Check out this tutorial on how to setup a basic Spring Boot application if you need to


If you are familiar with how to set up a Spring Boot application and want to just get the base source code for this tutorial, you can do so from GitHub

Web Application Skeleton – Tomcat (GitHub)


There is a very specific order of loading for external configurations. It’s useful to have this list at hand and often check for any changes, because this makes it easy to debug problems, related to application configuration.

What this tutorial contains


Basic properties file example

For the most basic example, create a file application.properties and place it inside the resources folder of your application. If you don’t have this folder, create it under /src/main.

Inside the application.properties file, add a single property

application.property.alpha=This property is set in the application.properties file

You can now use this property inside your Spring components, create a controller class, that will help us test different configuration options

The @Value annotation is what tells Spring to resolve a default value for our String property inside the controller, using a parameter identificator – in this case the property key, from the properties file that was created above.

If you are using the example skeleton application, start it by running the ApplicationConfiguration class and open the following URL in a browser

http://localhost:8080/config

This is the URL of the controller that was just created. The response should contain the property, defined in the application.properties file.

Hierarchical properties structure and automatic loading

If you have a more complex structure of properties you can use the @ConfigurationProperties annotation to load them up automatically in a separate class, representing your structure.

Add the following properties in the same application.properties file

service.name=Tutorial on simplyprogram.com
service.description=Spring Boot configuration example application
service.meta.author=Daniel
service.meta.year=2017

On a first glance you can tell that those properties have some structure. They all start with service.* and some of them obviously represent a nested object (meta.*) To load them up automatically, simply create the following classes

It makes sense for the meta.* properties to be an inner class, since this exactly represents the structure, defined in the application.properties file. The prefix argument for the @ConfigurationProperties annotation tells spring which properties we want to deserialize, so it’s possible to define numerous classes like this one and still use one properties file.

To use this component, simply autowire it inside your application

Calling the controller URL

http://localhost:8080/config

now yields the following response

Custom property files

You can define your own properties files, different from application.properties, since Spring will not automatically pick up any properties file inside your resourcefolder or any other classpath location. This is helpful when you want to logically separate your application configuration, the drawback is that currently only .properties files are supported out of the box. YAML support can be done, but this would require a bit of a custom implementation.

Create a file – specific.properties and place it in the resources folder, where your application.properties file resides.

To load properties from this file, create a class and annotate it with @PropertySource, which is quite self-explanatory. The @PropertySource annotation has some arguments, you’re going to give it the location of your properties source file you want to load and since the specific.properties file is on the classpath, you can omit “classpath” from the argument and simply enter the name of the file.

You can now use your specific properties by simply autowiring this class inside your Spring application

Calling

http://localhost:8080/config

now produces

Using configuration profiles

Spring supports different profiles for your configuration files. Different profiles help you set up your application for development, staging, UAT, production etc. environments. You don’t need to override each and every property you have, for example if you want you can override only specific properties for your development machine – enable debug logging, or disable application security etc. Properties you don’t override will still continue to be loaded from the default configuration files.

In the /resources folder, create the following file – application-dev.properties

The “*-dev” affix means that this configuration file is going to be used with the “dev” profile. You can name your profiles anything you want, they are not declared anywhere specifically, you just need to pass a command line argument to your application on startup.

In the dev properties file, let’s override the application.property.alpha 

application.property.alpha=Development profile

Depending on how you start your application you need to pass a command line argument, specifying the active profile. For IntelliJ, open Run/Debug Configurations and select the run configuration for your start class. In case you are using the application skeleton provided with this tutorial – that would be ApplicationConfiguration, the run configuration is named the same as the class.

In the VM options input field, add -Dspring.profiles.active=dev. This is a simple vm argument and you can add it if you are starting your application from the command line as well.

After running the application with the specified profile and calling the controller URL, the response shows that we’ve successfully overridden the intended property and retained the others

Basic YAML configuration file example

Other very popular format for your application configuration is YAML. In my opinion YAML is a bit more readable and it can visually represent hierarchies very well, but AFAIK it doesn’t really give you any advantages over using standard properties files.

In your /resources folder, create a file – application.yml. Since this file has a different extension, it will not conflict with the existing application.properties and both can be used simultaneously. And for the file content:

You can now resolve this property the same way as with the properties files, for example in the controller file

This results in

Hierarchical properties structure with YAML and automatic loading

Let’s create a simple hierarchical configuration, using YAML. Add the following to your application.yml file

To automatically load this document from the yml, create the following class, annotated with @ConfigurationProperties

This is the same example as with the .properties file.

To use the “database” properties, we’ve just set, just autowire the class anywhere in your application.

Calling the controller URL now produces

You can use profiles with YAML configuration files the same way as with the properties files.

Happy coding.


About the author

Daniel Vladimirov

Software engineer and founder of simplyprogram.com

Click here to add a comment

Leave a comment: