Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The Spring framework has garnered the interest of the Java developer’s community for over a decade as a lightweight alternative to EJB. It soon picked up as a de facto standard for numerous Web enterprise developments. The recent introduction of the Spring Boot project into the family of Spring has revolutionised the way a production-ready application is developed. Spring Boot enables developers to focus on the application logic rather than being bogged down by the intricacies of configuration. Spring has always prioritised convention over configuration as a model for simpler programming and Spring Boot Project emphasizes a similar discipline. Specifically, there are four main features that come with Spring Boot Project: starter dependencies, automatic configuration, CLI, and the actuator. This article delves briefly into the Spring Boot Project and analyses how it contributes to a simpler Spring programming model.
Double Trouble
Although Spring is considered to be lightweight enterprise development framework in comparison to EJB, one of the biggest complaints about it is that it depends upon a lot of configuration. In fact, it is these configurations that form the building block of Spring development. But, the problem is that there are too many on the verge of making an application development dense with numerous configuration codes. If we consider EJB a mess of heavyweight components, the Spring framework is definitely a mess of configuration. At the inception of Spring, the configurations were done in a XML file, but from Spring 2.5 onwards, the annotation-based component scanning feature was introduced. This cleared up a lot of explicit XML configuration issues. However, Spring 3.0 introduced Java-based configuration as a type-safe refactorable alternative to XML configuration. Although this idea lightened the configuration problem, it never eradicated them. For example, the use of Spring MVC and transaction management features still require explicit configuration. The use of many third-party libraries require explicit configuration. The servlet and filters need to be configured in a web.xml file or in a servlet initializer, and so on. Apart from these, meeting the right dependency for the project is another tricky problem. So, Spring has to solve not only the configuration issues but also the problem associated with library dependencies.
A Way to Solve the Problem
Spring has always favoured convention over configuration, which means it takes up the majority of working uses cases into consideration and goes by it rather than nit-picking an exact configuration and dependencies required for a specific application development. Picking an exact configuration is fine, but then, one has to hunt for exact dependent libraries with their matching versions and not forget that the dependent library has its own dependent libraries and so on. This often poses to be a nightmare for a project manager who has to deal with both configuration and dependency to run the application. What is interesting is that in most project development, we heavily need boilerplated code, such as a project structure with similar dependencies defined with Maven or Gradle. And, the project falls into one of the many known categories which require dependencies such as Spring MVC, Servlet API, JDBC, ORM, JPA, and so forth. If it is a Web application, we need an XML file to initiate the application, a controller class that responds to the HTTP request, and a Web application server such as Tomcat to deploy the application. There is actually very little code that is new to the application; the rest are repetitive, reusable, boilerplate code. So, Spring thought why not bootstrap them; provide these functionality behind the scene with minimal user’s intervention as possible. This is exactly what the Spring Boot project is all about.
Spring Boot in a Nutshell
According to the Spring Boot Project, Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can “just run.” What it does is scan the class path and configured beans of the application classes and makes an assessment of the missing items adds it into the project structure, all without the programmer’s intervention. This enables developers to focus more on the business logic of the application than project infrastructure, which is taken care of by Spring Boot. For example, Spring Boot automatically finds the specific beans declared in the project. There is no need to configure them explicitly; it automatically embeds Tomcat as the Web application server. In a nutshell, Spring Boot leverages the following features:
- Create stand-alone Spring applications
- Embed Tomcat, Jetty, or Undertow directly (no need to deploy WAR files)
- Provide opinionated ‘starter’ POMs to simplify your Maven configuration
- Automatically configure Spring whenever possible
- Provide production-ready features such as metrics, health checks, and externalized configuration
- Absolutely no code generation and no requirement for XML configuration
The Spring Boot Project provides four key features to begin it. They are typically called: starter dependencies, CLI, Automatic configuration, and the actuator. Let’s get a brief overview on each of them.
Starter Dependencies
The starters are basically a set of dependency descriptors tagged under a single banner, called starter name, such as spring-boot-starter-web. This starter includes all the dependent libraries required for developing a Spring Web application. Additional dependencies may be added, but in most cases the starter is sufficient for a particular category of project. Also, there is no harm in using more than one starter in pom.xml. Similarly, there is a starter called spring-boot-starter-test. This starter automatically includes almost all the libraries usually required for testing: Spring Test, JUnit, Hamcrest, and Mockito. Although dependencies can be added manually, Spring Boot Starters are rather more convenient.
For example, we can add spring-boot-starter-web for Web application development as follows. This automatically adds libraries like Spring MVC, REST, Tomcat, and Jackson.
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency>
Adding spring-boot-starter-test:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency>
Adding Data JPA starter with embedded h2 database:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <scope>runtime</scope> </dependency>
And so on. For more information on starters, refer to the Spring Boot starter documentation.
CLI (Command Line Interface)
Spring Boot provides a command line tool, called CLI (Command Line Interface), to quickly prototype a Spring application using Groovy Scripts. As mentioned, Spring Boot CLI is ideal for quick prototyping; production grade applications are rarely created using Spring Boot CLI. To use Spring Boot CLI, one needs to install a CLI distribution and create a Groovy file of the required application. Refer to the Spring Boot CLI documentation for detailed information on installing CLI and using it to create a quick prototype application with Groovy Scripts.
Automatic Configuration
This feature tries to automatically configure the application based upon the dependent libraries added to the project class path. For example, in a database application project the class that accesses the backend relational database with JDBC is generally annotated with @Bean and configured through JdbcTemplate in the Spring application context. This scenario is typical of any application that uses JDBC with a relational database. The code therefore used to configure the same is boilerplate and can be reused if provided. What Spring Boot does is completely take care of the boilerplate code and provide them without the need of the developer to configure them explicitly. This is what automatic configuration means. Spring Boot implicitly scans the application class path and detects the required database library and provides the necessary configuration to use it. If part of the code includes JdbcTemplate, it is also automatically configured. An automatic configuration scheme is not restricted to database use only. There are lots of other libraries that are automatically configured, provided they are in the Spring application class. path such as JPA, Security, Spring, and so on, to name a few.
The Actuator
The actuator basically enables inspection of a production-grade application by enabling auditing, health monitoring, and metric gathering features. The other Spring Boot features are primarily targeted towards development whereas the actuator exposes the internal runtime operational information, such as:
- Beans configured in the Spring Application Context
- Spring Boot’s auto-configuration
- Available environment variables, system and configuration properties, and the like
- Trace of a recent HTTP request
- Metrics of memory usage, garbage collection, data source usages, or Web request
We can use Web endpoints or SSH to inspect a running application. To enable the actuator, we may add the dependency as follows:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>
Refer to the documentation for detailed information on this.
Conclusion
Think of Spring Boot as another programmer who does all the dirty work of configuring and managing dependencies by intelligently sensing the direction of the project. It embeds the Tomcat server, configures servlet container, and bootstraps REST APIs if it senses that the application is a Web project. If it is a JPA or JDBC project that accesses relational database, it provides the necessary boilerplate code and configures it automatically. As a programmer, one needs to be aware what is going behind the scenes and focus on the business aspect of the project because managing and monitoring are already taken care of. Unless there is a specific need, tweaking the project structure provided by Spring Boot is almost unnecessary. Perhaps, programming cannot be simpler than this.
References
- Spring Boot Reference Guide
- Walls, Crag. Spring Boot in Action, Manning Publications
