Cloud Native Java

Chapter 3. Twelve-Factor Application Style Configuration

In this chapter, we’ll look at how to externalize application configuration.

The Confusing Conflation of “Configuration”

Let’s establish some vocabulary. When we talk about configuration in Spring, we’ve usually talked about the inputs into the Spring framework’s various ApplicationContext implementations that help the container understand how you want beans wired together. This might be an XML file to be fed into a ClassPathXmlApplicationContext, or Java classes annotated a certain way to be fed into an AnnotationConfigApplicationContext. Indeed, when we talk about the latter, we refer to it as Java configuration.

In this chapter, however, we’re going to look at configuration as it is defined in the Twelve-Factor application manifesto. In this instance, configuration refers to literal values that may change from one environment to another: things like passwords, ports and hostnames, or feature flags. This configuration defies magic constants embedded in the code. The manifesto provides a great litmus test for whether configuration has been done correctly: could the codebase of an application be open sourced at any moment without exposing and compromising important credentials? This sort of configuration refers only to the values that change from one environment to another; not, for example, to Spring bean wiring or Ruby route configuration.

Support in Spring Framework

Spring has supported twelve-factor–style configuration ...