Spring Boot is a technology for JAVA to use as a solution that encompasses the Spring framework. Basically, it aims at facilitating and speeding up the development of new projects, establishing a standard, and simplifying the way forward for the creation of Java applications quickly, robustly, and safely. It also guarantees its subsequent reproduction and scalability.
This article attempts to explore some changes and features planned for Spring Boot 2.0. Also, to describe how new changes can help and directly impact better production.
Main features
- Direct incorporation of web server/container applications such as Apache Tomcat or Jetty, eliminating the need to include WAR (Web Application Archive) files.
- Simplification of the Maven configuration thanks to the “Starter” POM (Project Object Models)
- Automatic Spring configuration as far as possible
- Non-functional features, such as metrics or outsourced configurations
The new Spring Boot 2 regarding Spring Boot
SpringBoot was launched in mid-2014, and SpringBoot 2.0 was launched in 2018.
First of all, it is necessary to point out that SpringBoot 2 requires that at least Java version 8 and SDK 9 be installed.
Other prerequisites regarding its minimum supported version are:
- Tomcat 8.5
- Hibernate 5.2
- Gradle 3.4
Dependency management is made through incoming and various package manager integrations. It tries to minimize the amount of initial configuration that an application requires and strengthens the existing convention by saving manual labor and using assistants.
It provides features ready for testing simulating production stories as an actuator, better recording, monitoring, metrics, or various PAAS integrations.
Improved development experience is obtained with multiple test utilities and a better feedback cycle using spring-boot-devtools.
The Gradle plugin has undergone significant improvements and some critical changes. To create large jars, the bootRepackage Gradle task is replaced with bootJar and bootWar to build jars and wars, respectively.
To run our applications with the Gradle plug-in, Gradle bootRun is used in 1.x. In 2.x bootRun extends the JavaExec from Gradle. This implies that it is easier than the sea configured by applying the same configuration that is typically used in classic JavaExec tasks.
In Spring Boot 2.x, the dependency management plug-in will no longer be applied by default. If you want to add Spring Boot dependency management, you must indicate:
apply plugin: 'io.spring.dependency-management'
This helps more flexibility with less configuration in a scenario where we don’t want to build a complete boot application or repackage it.
Regarding security in 2.x, the security configuration is greatly simplified. By default, everything is secured, including static resources and endpoints of the Actuator.
Once the user explicitly configures security, Spring Boot defaults will no longer affect. The user can set all access rules in one place.
This will prevent us from having problems with WebSecurityConfigurerAdapter orders. These problems used to occur generally when the Actuator and App security rules are configured in a personalized way.
Spring Boot 2 brings a set of new starters for different reactive modules. Some examples are WebFlux and the reactive counterparts for MongoDB, Cassandra, or Redis, as well as useful tools that allow us to create applications ready for production, such as the aforementioned Spring Boot Actuator. The actuator contains several tools to simplify supervision, monitoring, and general introspection of applications. With its version 2, the actuator has undergone significant improvements. This iteration focuses on simplifying customization. It is also compatible with other web technologies, including the new reactive module.
In Spring Boot 1.x, only Spring-MVC was compatible with Actuator endpoints, while in the version it is independent and connectable. Spring boot 2 provides immediate support for WebFlux, Jersey, and Spring-MVC. JMX remains an option and can be enabled or disabled through configuration.
The new Actuator infrastructure is independent of technology. Because of this, the development model was redesigned from scratch.
The new model also provides greater flexibility and expressiveness.
An example of how to create a Fruits endpoint for the Actuator:
In the Spring Boot 1.x version, the Actuator defines its own security model. This security model is different from the one used by the previous example. In version 2, the security settings must be configured using the same parameters used by the rest of the application.
By default, most Actuator endpoints are disabled. This is independent of whether Spring Security is in the classpath or not. Beyond status and information, the user must enable all other endpoints.
Another change is that most of the configuration properties are now in management.xxx, example: management.endpoints.jmx
Some EndPoints have a new format. example: env, flyway or liquibase
The predefined endpoint routes are no longer configurable.
Devtools is introduced in 1.3, which is responsible for handling caching problems of the fronted part. It also performs automatic restarts, reloads the browser at runtime, and allows applications to be debugged remotely.
Although it was not discussed in the article, it is valid to point out the advantage and existing recommendations on SpringBoot 2 and its orientation to microservices, which is an Intraway long-term policy for its products.s
