Spring Boot uses convention over configuration by scanning the dependent libraries available in the class path. For each spring-boot-starter-* dependency in the POM file, Spring Boot executes a default AutoConfiguration class. AutoConfiguration classes use the *AutoConfiguration lexical pattern, where * represents the library. For example, the autoconfiguration of JPA repositories is done through JpaRepositoriesAutoConfiguration.

Run the application with --debug to see the autoconfiguration report. The following command shows the autoconfiguration report for the chapter2.boot-advanced project:

$java -jar target/bootadvanced-0.0.1-SNAPSHOT.jar --debug

Here are some examples of the autoconfiguration classes:

It is possible to exclude the autoconfiguration of certain libraries if the application has special requirements and you want to get full control of the configurations. The following is an example of excluding DataSourceAutoConfiguration:

@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})

It is also possible to override default configuration values using the application.properties file. STS provides an easy-to-autocomplete, contextual help on application.properties, as shown in the following screenshot:

In the preceding screenshot, server.port is edited to be set as 9090. Running this application again will start the server on port 9090.

In order to align with the Twelve-Factor app, configuration parameters need to be externalized from the code. Spring Boot externalizes all configurations into application.properties. However, it is still part of the application's build. Furthermore, properties can be read from outside the package by setting the following properties:

spring.config.name= # config file name  
spring.config.location= # location of config file

Here, spring.config.location could be a local file location.

The following command starts the Spring Boot application with an externally provided configuration file:

$java -jar target/bootadvanced-0.0.1-SNAPSHOT.jar --spring.config.name=bootrest.properties

At startup, SpringApplication loads all the properties and adds them to the Spring Environment class. Add a custom property to the application.properties file. In this case, the custom property is named bootrest.customproperty. Autowire the Spring Environment class into the GreetingController class. Edit the GreetingController class to read the custom property from Environment and add a log statement to print the custom property to the console.

Perform the following steps to do this:

As an alternate to application.properties, one may use a .yaml file. YAML provides a JSON-like structured configuration compared to the flat properties file.

To see this in action, simply replace application.properties with application.yaml and add the following property:

server
  port: 9080

Rerun the application to see the port printed in the console.

Furthermore, it is possible to have different profiles such as development, testing, staging, production, and so on. These are logical names. Using these, one can configure different values for the same properties for different environments. This is quite handy when running the Spring Boot application against different environments. In such cases, there is no rebuild required when moving from one environment to another.

Update the .yaml file as follows. The Spring Boot group profiles properties based on the dotted separator:

spring:
    profiles: development
server:
      port: 9090
---

spring:
    profiles: production
server:
      port: 8080

Run the Spring Boot application as follows to see the use of profiles:

mvn -Dspring.profiles.active=production install
mvn -Dspring.profiles.active=development install

Active profiles can be specified programmatically using the @ActiveProfiles annotation, which is especially useful when running test cases, as follows:

@ActiveProfiles("test")

The properties can be loaded in a number of ways, such as the following: