The labs on this site need JavaScript to run. The same content is written out below.
Learn › Spring › Spring Boot
Configuration precedence
When the same property is set in several places, which value wins?
Spring Boot reads property values from several places, such as files, environment variables, and command-line arguments. When the same key is set in more than one place, the place with the higher precedence wins.
Checked against real execution · 32 combinations were run on Spring Boot 4.1.1 and checked against the results
Concepts in this lab
- Externalized configuration and profiles
- Externalized configuration means supplying setting values such as a DB address through configuration files, environment variables, command-line arguments, and so on, without putting them in the code. It lets you run the same build artifact with different settings in different environments. A profile is a feature that keeps groups of settings separated by environment, such as development and production, and lets you select one at run time.
- Spring Boot auto-configuration
- This Spring Boot feature looks at the libraries on the classpath and at the configuration values, and automatically registers the beans that are needed. For example, if a JDBC driver and connection details are present, it configures a DataSource automatically. Each auto-configuration has conditions for when it applies, and if the developer registers a bean of the same kind directly, the part of the auto-configuration that creates that bean does not apply.
- CI/CD
- CI (continuous integration) means merging code changes often and automatically running a build and tests on every merge to find problems early. CD (continuous delivery or continuous deployment) means using an automated process to get verified code into a deployable state or to deploy it all the way to production. Automating the build, test, and deployment work that people used to do by hand reduces mistakes and shortens the release cycle.
Try these
- Default settings — Both application.yml and the prod file have the value. The prod file wins.
- Adding an environment variable — An environment variable takes precedence over the files. This is a common approach in container deployments.
- Adding a command-line argument too — Command-line arguments have the highest precedence.
- application.yml only — When no other place has the value, the value in application.yml is used.
- Not set anywhere — The default value written in the code is used.
Running with the default settings
- As the application starts, it looks for the value of app.timeout. Spring Boot checks several places in a fixed order and uses the value found in the place with the highest precedence. The steps go through the places from the highest precedence down.
- 1. Command-line argument: This key is not set here. The search moves on to the next place.
- 2. JVM system property: This key is not set here. The search moves on to the next place.
- 3. OS environment variable: This key is not set here. The search moves on to the next place.
- 4. application-prod.yml: The value 5000 is found here. No place with a higher precedence had a value, so this is the final value.
- 5. application.yml: The value 3000 is set here, but the value was already decided at a higher precedence. This value is not used.
Result of this run
- From highest to lowest, the precedence is command-line arguments → JVM system properties → environment variables → the profile-specific file → application.yml. The closer a place is to the side that runs the application, the higher its precedence.
- Thanks to this order, you can run the same build artifact (a jar or an image) with different values in each environment without modifying it. Values that differ from one environment to another, or that must not be put in the code repository, such as a database URL or a password, are passed in through environment variables or injected at run time.
Code
@Value("${app.timeout:1000}") // 1000 if not set anywhere
private int timeout;
# application.yml
app.timeout: 3000
# application-prod.yml
app.timeout: 5000
# Run
java -jar app.jar --spring.profiles.active=prod
Assumptions of this model
This lab picks only five commonly used places from the externalized configuration order in the official Spring Boot documentation. The real list has more, such as SPRING_APPLICATION_JSON and configuration files outside the jar (which take precedence over the files inside the jar). A profile-specific file is read only when that profile is active. All 32 combinations were run on real Spring Boot 4.1.1, with a new process started for each combination, and the final value and the place it came from were confirmed to match the screen.
Previous lab: Spring Boot auto-configuration · Next lab: Actuator and health checks