1. Overview
Spring Boot is an opinionated framework. Despite this, we usually end up overriding autoconfigured properties in an application configuration file such as application.properties.
However, in a Spring Cloud application, we often use another configuration file called bootstrap.properties.
In this quick tutorial, we'll explain the differences between bootstrap.properties and application.properties.
2. When Is the Application Configuration File Used?
We use application.yml or application.properties for configuring the application context.
When a Spring Boot application starts, it creates an application context that doesn't need to be explicitly configured – it's already autoconfigured. However, Spring Boot offers different ways to override these properties.
We can override these properties in code, command-line arguments, ServletConfig init parameters, ServletContext init parameters, Java system properties, operating system variables, and application properties file.
An important thing to keep in mind is that these application properties files have the lowest precedence compared to other forms of overriding application context properties.
We tend to group properties that we can override in the application context:
- Core properties (logging properties, thread properties)
- Integration properties (RabbitMQ properties, ActiveMQ properties)
- Web properties (HTTP properties, MVC properties)
- Security properties (LDAP properties, OAuth2 properties)
3. When Is the Bootstrap Configuration File Used
We use bootstrap.yml or bootstrap.properties for configuring the bootstrap context. This way we keep the external configuration for bootstrap and main context nicely separated.
The bootstrap context is responsible for loading configuration properties from the external sources and for decrypting properties in the local external configuration files.
When the Spring Cloud application starts, it creates a bootstrap context. The first thing to remember is that the bootstrap context is the parent context for the main application.
Another key point to remember is that these two contexts share the Environment, which is the source of external properties for any Spring application. In contrast with the application context, the bootstrap context uses a different convention for locating the external configuration.
The source of configuration files can be a filesystem or even a git repository, for example. The services use their spring-cloud-config-client dependency to access the configuration server. To put it in simple words, the configuration server is the point through which we access the application context configuration files.
In this example, the bootstrap context configuration file configures the spring-cloud-config-client dependency to load the right application properties files.
Let's see an example of a bootstrap.properties file:
spring.application.name=config-client spring.profiles.active=development spring.cloud.config.uri=http://localhost:8888 spring.cloud.config.username=root spring.cloud.config.password=s3cr3t spring.cloud.config.fail-fast=true management.security.enabled=false
4. Conclusion
In contrast to a Spring Boot application, a Spring Cloud application features a bootstrap context that is the parent of the application context. Although both of them share the same Environment, they have different conventions for locating the external configuration files.
The bootstrap context is searching for a bootstrap.properties or a bootstrap.yaml file, whereas the application context is searching for an application.properties or an application.yaml file. The configuration properties of the bootstrap context load before the configuration properties of the application context.