Spring Boot has always been a key participant in the Spring ecosystem. This project makes our life easier through its automatic configuration function. In this tutorial, we will introduce some of the most common Spring Boot-related questions that may arise in a job interview.
What is the difference between Spring and Spring Boot?
Spring Framework provides multiple functions to make the development of web applications easier. These functions include dependency injection, data binding, aspect-oriented programming, data access and so on.
Over the years, Spring has become more and more complex, and the amount of configuration required for such applications can be daunting. This is where Spring Boot comes in handy-it makes configuring Spring applications a breeze.
In essence, although Spring is unpopular, Spring Boot has its own view of the platform and libraries, let us get started quickly.
The following are the two most important benefits of Spring Boot:
Automatically configure applications based on artifacts found in the classpath
Provide non-functional features common to applications in production, such as security or health checks
More SpringBoot tutorials
How do we set up a Spring Boot application using Maven?
We can include Spring Boot in a Maven project just like any other library. However, the best way is to inherit from the spring-boot-starter-parent project and declare a dependency on the Spring Boot starter. Doing so allows our project to reuse Spring Boot's default settings.
Inheriting the spring-boot-starter-parent project is very simple-we only need to specify a parent element in pom.xml:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.1.RELEASE</version>
</parent>
We can find the latest version of spring-boot-starter-parent in Maven Central.
Using the startup parent project is convenient, but not always feasible. For example, if our company requires all projects to be inherited from the standard POM, we cannot rely on the startup parent of Spring Boot.
In this case, we can still get the benefits of dependency management through this POM element:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>2.1.1.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Are there any Spring Boot starters to choose from?
Dependency management is a key aspect of any project. When the project is sufficiently complex, managing dependencies can become a nightmare because there are too many artifacts involved.
This is where Spring Boot starters come in handy. Every beginner can serve as a one-stop service for all the Spring technologies we need. Then, communicate and manage other required dependencies in a consistent manner.
All starters are under the org.springframework.boot group, and their names start with spring-boot-starter-. This naming pattern makes it easy to find the launcher, especially when using an IDE that supports searching dependencies by name.
At the time of writing, we have more than 50 launchers. The most commonly used are:
spring-boot-starter: core starter, including automatic configuration support, logging and YAML
spring-boot-starter-aop: use Spring AOP and AspectJ for aspect-oriented programming
spring-boot-starter-data-jpa: use Spring Data JPA and Hibernate's starter
spring-boot-starter-jdbc: A starter used to use JDBC with HikariCP connection pool
spring-boot-starter-security: Use Spring Security's starter
spring-boot-starter-test : Starter for testing Spring Boot applications
spring-boot-starter-web: Starter for building the web, including RESTful applications using Spring MVC
For a complete list of starters, please refer to this repository
How to disable specific automatic configuration?
If we want to disable a specific automatic configuration, we can use the exclude attribute of the @EnableAutoConfiguration annotation to indicate it
// other annotations
@EnableAutoConfiguration(exclude = DataSourceAutoConfiguration.class)
public class MyConfiguration { }
If we use the @SpringBootApplication annotation to enable auto-configuration-it has @EnableAutoConfiguration as a meta-annotation-we can disable auto-configuration using the attribute of the same name:
// other annotations
@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)
public class MyConfiguration { }
We can also disable automatic configuration using the spring.autoconfigure.exclude environment property. This setting in the application.properties file is the same as before:
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
####How to register a custom automatic configuration?
To register an automatic configuration class, we must list its fully qualified name under the EnableAutoConfiguration key in the META-INF/spring.factories file:
org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.baeldung.autoconfigure.CustomAutoConfiguration
If we use Maven to build a project, then the file should be placed in the resources/META-INF directory, which will be found in the program packaging stage.
How to tell auto-configuration to return if the bean already exists?
To instruct the auto-configuration class to exit when the bean already exists, we can use the @ConditionalOnMissingBean annotation. The most notable attributes of this annotation are:
value: the type of bean to be checked
name: the name of the bean to be checked When
placed on a method decorated with @Bean, the target type defaults to the return type of the method:
@Configuration
public class CustomConfiguration {
@Bean
@ConditionalOnMissingBean
public CustomService service() { ... }
}
How to deploy Spring Boot web applications as JAR and WAR files?
Traditionally, we packaged web applications as WAR files and then deployed them to external servers. Doing so allows us to arrange multiple applications on the same server. This is a good way to save resources when CPU and memory are scarce.
But things have changed. Computer hardware is now fairly cheap, and attention is turning to server configurations. A small mistake in configuring the server during deployment can lead to catastrophic consequences.
Spring solves this problem by providing a plug-in, spring-boot-maven-plugin, to package the web application as an executable JAR. To include this plugin, just add a plugin element to pom.xml:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
With this plugin, we will generate a fat JAR after executing the packaging phase. This JAR contains all the necessary dependencies, including the embedded server. Therefore, we no longer need to worry about configuring external servers.
Then we run the application just like a normal executable JAR.
Please note that the packaging element in the pom.xml file must be set to jar to build the JAR file:
After the jar
executes the Maven packaging phase, we will have a deployable WAR file.
How to use Spring Boot for command line applications?
Like any other Java program, a Spring Boot command line application must have a main method. This method is used as the entry point, it calls the SpringApplication#run method to bootstrap the application:
@SpringBootApplication
public class MyApplication {
public static void main(String[] args) {
SpringApplication.run(MyApplication.class);
// other statements
}
}
Then the SpringApplication class starts a Spring container and automatically configures the beans.
Please note that we must pass the configuration class to the run method to be used as the main configuration source. By convention, this parameter is the entry class itself.
After calling the run method, we can execute other statements as in a regular program.
What are the possible sources of external configuration?
Spring Boot supports external configuration, allowing us to run the same application in various environments. We can use property files, YAML files, environment variables, system properties and command-line option parameters to specify configuration properties.
Then, we can access these properties using @Value annotation, via the @ConfigurationProperties annotation of the binding object, or environment abstraction.
The following are the most common sources of external configuration:
Command line attributes: Command line option parameters are program parameters that start with a double hyphen, for example -server.port = 8080. Spring Boot converts all parameters into attributes and adds them to the environment attribute set.
Application properties: Application properties are properties loaded from the application.properties file or its YAML corresponding file. By default, Spring Boot will search for this file in the current directory, the root of the classpath or its config subdirectory.
Profile-specific properties: Profile-specific properties are loaded from the application-{profile}.properties file or its YAML corresponding file. {profile} refers to the name of the active profile. These files are located in the same location as the non-specific properties files and take precedence over the non-specific properties files.
What does it mean that Spring Boot supports easy binding?
Easy binding in Spring Boot is suitable for type-safe binding of configuration properties.
When loose binding is used, the key of the environment property does not need to exactly match the property name. Such environmental attributes can be written in camelCase, kebab-case, snake_case or capital letters, with words separated by underscores.
For example, if the property in the bean class with @ConfigurationProperties annotation is named myProp, you can bind it to any of the following environment properties: myProp, my-prop, my_prop, or MY_PROP.
What is Spring Boot DevTools?
Spring Boot Developer Tools or DevTools is a set of tools that make the development process easier. To include these development-time features, we only need to add dependencies in the pom.xml file:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
</dependency>
In the production run module, Spring Boot devtools will be automatically disabled. By default, repackaging archives will also exclude this module. Therefore, it will not bring any overhead to our final product.
By default, DevTools applies properties suitable for the development environment. These properties disable template caching, enable debug logging for web groups, and so on. Therefore, we have such a reasonable development-time configuration without setting any properties.
As long as the files on the classpath change, applications that use DevTools will restart. This is a very useful feature in development, because it can quickly feedback changes.
By default, static resources (including view templates) will not initiate a restart. Conversely, resource changes will trigger a browser refresh. Please note that this happens only when the LiveReload extension is installed in the browser to interact with the embedded LiveReload server included in DevTools.
Idea needs to be specifically configured through running configuration.
How to write integration tests?
When running integration tests for Spring applications, we must have an ApplicationContext.
To make our lives easier, Spring Boot provides a special annotation for testing-@SpringBootTest. This annotation creates an ApplicationContext from the configuration class indicated by its classes attribute.
If the classes attribute is not set, Spring Boot will search for the main configuration class. The search starts from the package containing the test until you find a class annotated with @SpringBootApplication or @SpringBootConfiguration.
Please note that if we use JUnit 4, we must decorate the test class with @RunWith(SpringRunner.class).
What is Spring Boot Actuator
Essentially, Actuator turns Spring Boot applications into reality by supporting production-ready features. These features allow us to monitor and manage applications while running in production.
Integrating Spring Boot Actuator into a project is very simple. All we need to do is include the spring-boot-starter-actuator starter in the pom.xml file:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Spring Boot Actuator can use HTTP or JMX endpoints to expose operating information. However, most applications use HTTP, where the identification of the endpoint and the /actuator prefix form the URL path.
Here are some of the most common built-in endpoints provided by Actuator:
- auditevents: public audit event information
- env: public environment properties
- health: Display application health information
- httptrace: Display HTTP trace information
- info: Display information about any application
- metrics: display metric information
- loggers: Display and modify the configuration of loggers in the application
- mappings: Display a list of all @RequestMapping paths
- scheduledtasks: Display scheduled tasks in the application
- threaddump: Perform thread dump