Introduction to Spring Boot

1. Spring Boot Introduction

While Spring already provides a strong MVC framework, Transaction Management, Messaging support, Web Services, etc, Spring Boot came by storm and started shadowing it by taking over the hassles of configurations, thus considerably reducing the development time.

Let’s elaborate what Spring Boot benefits us with. What if –

  • There could be someone who could find all the compatible libraries for the specific Spring version and configure it for us.
  • There could be someone who could auto-configure things that we tediously used to do with Spring, like configuring the DataSourceEntitymanagerFactoryTransactionManager, etc.
  • There could be someone who could configure the most commonly used SpringMVC beans like ViewResolver, MessageSource, etc.

The quick response to all such needs is – Yes! There is Spring Boot for you.

2. Spring Boot Features

With Spring Boot you can –

  • Create stand-alone Spring applications with Tomcat/Jetty embedded, such that an executable JAR is enough, compared to installing and upgrading Tomcat in target environment.
  • Run your app in multiple ways –  java -jar, new run goal mvn spring-boot:run or traditional WAR deployment.
  • Simplified Maven configuration without any chances of version collisions.
  • There is virtually no XMLs involved.
  • Auto-magically configure most of the needed components.
  • Provide production-ready features such as metrics, health checks and externalized configuration.

With standalone self-sufficient Spring applications, we can save the deployment process completely by embedding the server resources within an executable JAR, instead of a WAR. This would save additional costs in external servlet container setup (eg. Tomcat), maintenance and manual deployments.

3. Spring Boot Modules

There are several Spring Boot modules that we will soon become more practically familiar with. To list out some of them below –

3.1 spring-boot

This is the main Spring Boot library, which includes features like –

  • There is a SpringApplication class, whose main job is to create and refresh the Spring application context. It bootstraps the Spring application starting from the main() method using static method.
  • Can embed a choice of servlet container (Tomcat/Jetty) within itself.
  • Provides externalized configuration support.
  • Application context initializers and support for sensible logging defaults.

3.2 spring-boot-autoconfigure

@EnableAutoConfiguration annotation triggers auto-configuration of the Spring application context, based on the contents that exists in the classpath.

This module consists of AutoConfiguration classes, which are annotated with @Configuration, to mark them as configuration classes. There are @Conditional annotations used within these Spring Boot configuration classes, which register the bean definitions only when the conditions are matched. Like, DataSourceAutoConfiguration will be initiated only if the DataSource.class and EmbeddedDatabaseType.class classes are available in the classpath.

Once the DataSourceAutoConfiguration condition is matched, @EnableConfigurationProperties (DataSourceProperties.class) enables binding the properties in (src/main/resources/ to the corresponding properties of DataSourceProperties class automatically. All you need to do is make proper entries into your property file, such that the DataSource related properties start with spring.datasource.*. For eg –

There are other AutoConfiguration classes that have their own conditions before they initiate. Some of them are –

  • org.springframework.boot.autoconfigure.web.DispatcherServletAutoConfiguration
  • org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration

3.3 spring-boot-starters

Starters are some amazing set of dependency descriptors, that helps you set up auto-magically exactly what you need to. Like if you want to create a Spring and JPA based application, you just need to include spring-boot-starter-data-jpa dependency in your application.

The whole list of starters can be seen here.

3.4 spring-boot-cli

The Spring Boot CLI is a command line tool that can be used if you want you quickly make your Spring application up and running. With Spring Boot CLI, you can run Groovy scripts, which has a similar syntax as Java, without writing so much boilerplate code, and kick-start your Spring application. Spring CLI can also watch files, automatically recompiling and restarting whenever they change. For example –

To compile and run the application, just type the following –

3.5 spring-boot-actuator

Spring Boot Actuator is a number of additional features to help you monitor and manage your application when it’s pushed to production. The simplest way to enable the features is to add a dependency to the spring-boot-starter-actuator ‘Starter’. For example, Actuator provides us with endpoints without explicitly specifying our own, thus allowing us to monitor and interact with our application. By default, the health endpoint will be mapped to /health.

3.6 spring-boot-loader

The Spring Boot Loader module allows JAR and WAR files that contain nested dependencies (JAR within JAR) to be run using java -jar archive.jar.

There are 3 launcher classes (JarLauncher, WarLauncher and PropertiesLauncher). Their purpose is to load resources (.classfiles etc.) from nested JAR files or JAR files in directories. In the case of the [Jar|War]Launcher the nested paths are fixed (lib/*.jar and lib-provided/*.jar in case of WAR), so we just add extra JARs in those locations if we want more. The PropertiesLauncher looks in lib/ by default, but we can add additional locations by setting an environment variable LOADER_PATH or loader.path in (colon-separated list of directories or archives).

If we are already using the Maven or Gradle plugin, executable jars are automatically generated and we generally won’t need to know the details of how they work.

Java does not provide any standard way to load nested jar files (i.e. jar files that are themselves contained within a jar). This can be problematic if you are looking to distribute a self contained application that you can just run from the command line without unpacking. To solve this problem, many developers use ‘shaded’ jars.

A shaded jar simply packages all classes, from all jars, into a single ‘uber jar’. The problem with shaded jars is that it becomes hard to see which libraries you are actually using in your application. It can also be problematic if the the same filename is used (but with different content) in multiple jars. Spring Boot takes a different approach and allows you to actually nest jars directly.

4. Conclusion

Hopefully we now know about the capabilities of Spring Boot on a high level. We will come up with a very basic Spring Boot application in the next tutorial.

Credits –

Receive our updates to your inbox

Get more stuff like this
in your inbox

Subscribe to our mailing list and get interesting stuff and updates to your email inbox.