We just got things off the ground with an operational application, but that isn't the only killer feature of Spring Boot.
Spring Boot comes with a fistful of prebuilt properties. In fact, just about every autoconfigured component has some property setting (http://docs.spring.io/spring-boot/docs/2.0.0.M5/reference/htmlsingle/#common-application-properties) allowing you to override just the parts you like.
Many of these autoconfigured beans will back off if Boot spots us creating our own. For example, when Spring Boot spots reactive MongoDB drivers on the classpath, it automatically creates a reactive MongoClient. However, if we define our own MongoClient bean, then Spring Boot will back off and accept ours.
This can lead to other components switching off. But sometimes, we don't need to swap out an entire bean. Instead, we may wish to merely tweak a single property of one of these autoconfigured beans.
Let's try to make some adjustments to src/main/resources/application.properties as follows:
# Override the port Tomcat listens on
server.port=9000
# Customize log levels
logging.level.com.greglturnquist=DEBUG
This preceding changes will cause Spring Boot to launch Netty on port 9000, as shown here:
2017-08-02 15:40:02.489: Netty started on port(s): 9000
It will also bump up the log level for package com.greglturnquist to DEBUG.
While it's handy to externalize configuration settings into property files, it wouldn't be a big advantage if they were only embeddable inside our app's JAR file.
That's why, Spring Boot comes with property override support. The following list shows all the locations from which we can override properties, the first being the highest priority:
- The @TestPropertySource annotation on test classes
- Command-line arguments
- The properties found inside SPRING_APPLICATION_JSON (inline JSON embedded in an env variable or system property)
- The ServletConfig init parameters
- The ServletContext init parameters
- The JNDI attributes from java:comp/env
- The Java System properties (System.getProperties())
- The OS environment variables
- A RandomValuePropertySource that only has properties in random.*
- Profile-specific properties outside the packaged JAR file (application-{profile}.properties and YAML variants)
- Profile-specific properties inside the packaged JAR file (application-{profile}.properties and YAML variants)
- Application properties outside the package JAR file (application.properties and YAML variants)
- Application properties inside the packaged JAR file (application.properties and YAML variants)
- The @PropertySource annotation on any @Configuration classes
- Default properties (specified using SpringApplication.setDefaultProperties)
For an example of the same overrides in YAML format as our application.properties file, we could put the following in application.yml in src/main/resources:
server:
port: 9000
logging:
level:
com:
greglturnquist: DEBUG
This would do the exact same thing that we already saw with application.properties. The only difference is the formatting.
What are the benefits of YAML over properties? If we need to override lots of settings, it avoids duplication of various keys.
Spring properties can also reference other properties, as shown in this fragment:
app.name=MyApp
app.description=${app.name} is a Spring Boot application
In this preceding example, the second property, app.description, references the first property, app.name.
This isn't the end of options with property overrides. It's just the beginning. Throughout this book, we'll expand on the options provided by Spring Boot's property support.
For now, let's focus on getting our app to production!