Spring Boot 2.0 Projects: Build production-grade reactive applications and microservices with Spring Boot

To open the generated project with IntelliJ, we perform the following steps:

To open the generated project the Spring Tool Suite, we perform the following steps:

The source code for this chapter can be found at https://github.com/PacktPublishing/Spring-Boot-2.0-Projects-Fundamentals-of-Spring-Boot-2.0, in the Chapter01 directory.

Spring Boot is an application development framework for the Java virtual machine (JVM) that enables users to write stand-alone, production-grade, flexible, and extensible Spring-based applications with minimum code and configurations. This follows the Rapid application development (RAD) paradigm where the focus is on writing business logic that matters. With the introduction of cloud-based hosting services and microservice architectures, Spring Boot has been further elevated into a must-know technology platform. The following are some of its features:

Spring Boot does not do any code generation and does not require any XML files to be configured in order to run. Spring Boot is ideal for on-premise and cloud-based deployments with a quick boot-up time and a good memory footprint. The uniqueness of Spring Boot comes from its ecosystem of Spring modules, which covers security, data persistence, batch processing, and so on and from the highly active, competent community of developers who keep on improving the Spring Boot Framework.

<parent>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-parent</artifactId>
   <version>1.5.9.RELEASE</version>
   <relativePath/> <!-- lookup parent from repository -->
</parent>

<dependencies>
   <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter</artifactId>
   </dependency>
   ...
</dependencies>

import org.springframework.boot.ApplicationRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;

@SpringBootApplication
public class SpringBootIntroApplication {

public static void main(String[] args) {
      SpringApplication.run(SpringBootIntroApplication.class, args);
}

@Bean
public ApplicationRunner applicationRunner() {
return args -> {
         System.out.println("Hello, World!");
};
}
}

$ mvn clean install
$ java -jar target/<package-name>.[jar|war]

$ mvn clean spring-boot:run

Spring Boot allows Builder to create customized Spring Boot application bootstrapping with a tool called SpringApplicationBuilder. This can be used as follows to customize the Spring Boot application and register a Spring Bean dynamically:

public static void main(String[] args) {
new SpringApplicationBuilder(SpringBoot2IntroApplication.class)
         .bannerMode(Banner.Mode.OFF)
         .initializers((GenericApplicationContext 
           genericApplicationContext) -> {
            genericApplicationContext.registerBean
            ("internet", 
             InternetHealthIndicator.class);
})

         .run(args);
}

In this code, a new instance of SpringApplicationBuilder is instantiated with a configuration class. By invoking the bannerMode(Banner.Mode.OFF) method, the banner shown in the console at the Spring Boot Bootstrap is switched off. 

By invoking the initializers() method with a lambda function (learn about lambda functions in the reference documentation at https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html) for ApplicationContextInitializer, the GenericApplicationContext.registerBean method is used to register a Spring Bean called internet and with class type InternetHealthIndicator. 

Configuration properties are a great feature of Spring Boot for reading properties with type safety. This section will explain the concept with the following DemoApplicationProperties class file:

@ConfigurationProperties(prefix = "demo")
public class DemoApplicationProperties {

private Integer number;

    private String username;

    private String telephoneNumber;

    private List<String> emailAddresses = 
    Arrays.asList("[email protected]");

    private String firstName;

    private String lastName;

    private Duration workingTime;

    // Getters and Setters
}

The application.yml has the following configuration properties:

demo:
  number: 10
user-Name: shazin
firstName: Shazin
lAsTNamE: Sadakath
telephone_number: "0094777329939"
workingTime: 8h
EMAILADDRESSES:
- [email protected]
    - [email protected]
addresses:
- number: "B 22 2/3"
city: Colombo
street: "Ramya Place"
country: "Sri Lanka"
zipCode: "01000"
- number: "123"
city: Kandy
street: "Dalada Weediya"
country: "Sri Lanka"
zipCode: "01332"

For configuration properties, an application.properties file also can be used over an application.yml file. Lately, YML files are becoming famous among developers because they can provide a structure with indentations, the ability to use collections, and so on. Spring Boot supports both at the moment.

public class Address {
private String number;
    private String street;
    private String city;
    private String country;
    private String zipCode;
    // Getters, Setters, Equals, Hashcode
}

List<Address> addresses = Binder.get(environment)
      .bind("demo.addresses", Bindable.listOf(Address.class))
      .orElseThrow(IllegalStateException::new);

"demo.user-Name": {
"value":"shazin",
"origin":"class path resource [application.yml]:5:14"
}

DEMO_ENV_1 = demo.env[1]
DEMO_ENV_1_2 = demo.env[1][2]

System.out.printf("Demo Env 1 : %s\n", environment.getProperty("demo.env[1]"));

In Spring Boot 1.x, in order to write a custom endpoint for Spring Boot Actuator, AbstractEndpoint had to be extended and its invoke method has been overridden with custom logic. Spring Boot Actuator is a production-ready feature for monitoring and managing a Spring Boot application using HTTP endpoints or JMX. Auditing metrics such as health could also be gathered using this feature. Finally, it had to be injected into the Spring Context as a Bean. This endpoint was technologically agnostic, in the sense that it could be invoked using JMX as well as with web requests.

If a custom behavior was required for a particular technology, such as JMX or the web, then AbstractEndpointMvcAdapter or EndpointMBeanhad to be extended respectively and had to be injected as a Spring Bean. This is cumbersome, and Spring Boot 2.0 has introduced technology-specific annotations such as @Endpoint, @WebEndpoint, and @JmxEndpoint; technology-independent operation annotations such as @ReadOperation,@WriteOperation, and @DeleteOperation; and technology-specific extension annotations such as  @EndpointWebExtension and @EndpointJmxExtension, to ease this process.

@Component
@Endpoint(id = "custom")
public class CustomEndpoint {

private final static Logger LOGGER = 
     LoggerFactory.getLogger(CustomEndpoint.class);

@ReadOperation
public String get() {
return "Custom Endpoint";
}

@WriteOperation
public void set(String message) {
LOGGER.info("Custom Endpoint Message {}", message);
}
}

@Component
@EndpointWebExtension(endpoint = CustomEndpoint.class)
public class CustomEndpointWebExtension {
    ...

@ReadOperation
public WebEndpointResponse<String> getWeb() {
        ...
        return new WebEndpointResponse<>("Custom Web 
          Extension Hello, World!", 200);
}
}

Custom Web Extension Hello, World!

Connecting to a custom endpoint using monitoring and management tools

Running the Spring Boot application with the following VM arguments will enable it to be connected using jconsole remotely, and the exposed CustomEndpoint JMX Bean can be accessed using monitoring and management tools such as jconsole, which is shipped with the JDK installation:

-Djavax.management.builder.initial=      
-Dcom.sun.management.jmxremote      
-Dcom.sun.management.jmxremote.port=8855      
-Dcom.sun.management.jmxremote.authenticate=false      
-Dcom.sun.management.jmxremote.ssl=false

Run jconsole with the following command:

$ jconsole

Making a remote process connected with it to<host>:8855 will list all the MBeans from the Spring Boot application under MBeans tab. When the Custom.get operation is executed from jconsole it will show the return from CustomEndpoint.get as expected, as shown in the following screenshot:

With the introduction of Micrometer to Spring Boot Actuator in Spring Boot 2.0, metrics can be customized easily. The following code snippet from CustomEndpointWebExtension shows how to make use of io.micrometer.core.instrument.MeterRegistry to maintain a counter with the name custom.endpoint.calls, which will be incremented every time CustomEndpointWebExtension is invoked:

public static final String CUSTOM_ENDPOINT_CALLS = "custom.endpoint.calls";

private final MeterRegistry meterRegistry;

public CustomEndpointWebExtension(MeterRegistry meterRegistry) {
this.meterRegistry = meterRegistry;
}

@ReadOperation
public WebEndpointResponse<String> getWeb() {
meterRegistry.counter(CUSTOM_ENDPOINT_CALLS).increment();
    return new WebEndpointResponse<>("Custom Web Extension Hello, World!", 200);
}

The preceding code injects MeterRegistry from the Micrometer Framework, which is used to create and retrieve a counter named custom.endpoint.calls and increment it during each read operation of the custom web endpoint extension.

This metric will be available under the http://<host>:<port>/actuator/metrics/custom.endpoint.calls URL, which will show a result similar to the following:

{
"name":"custom.endpoint.calls",
"measurements":[
{
"statistic":"COUNT",
"value":3.0
}
],
"availableTags":[]
}

Spring Boot Actuator's health endpoint is really helpful for checking the status of Spring Boot application and dependent systems such as databases, message queues, and so on. Spring Boot ships out of the box with many standard HealthIndicator implementations such as DiskSpaceHealthIndicator, DataSourceHealthIndicator, and MailHealthIndicator, which can all be used in Spring Boot applications with Spring Boot Actuator. Furthermore, custom health indicators can also be implemented if required:

public class InternetHealthIndicator implements HealthIndicator {

private static final Logger LOGGER = LoggerFactory.getLogger(InternetHealthIndicator.class);

    public static final String UNIVERAL_INTERNET_CONNECTIVITY_CHECKING_URL = "https://www.google.com";

    private final RestTemplate restTemplate;

    public InternetHealthIndicator(RestTemplateBuilder restTemplateBuilder) {
this.restTemplate = restTemplateBuilder.build();
}

@Override
public Health health() {
try {
            ResponseEntity<String> response = restTemplate.getForEntity(UNIVERAL_INTERNET_CONNECTIVITY_CHECKING_URL, String.class);
LOGGER.info("Internet Health Response Code {}", 
              response.getStatusCode());
            if (response.getStatusCode().is2xxSuccessful()) {
return Health.up().build();
}
        } catch(Exception e) {
LOGGER.error("Error occurred while checking
              internet connectivity", e);
            return Health.down(e).build();
}

return Health.down().build();
}
}

The preceding InternetHealthIndicator is intended to show the status of internet connectivity from within Spring Boot applications to the outside world. It will send a request to www.google.com to check whether it sends a successful HTTP response code, and based on that the health status of this indicator will be set to up or down. This was injected as a Spring Bean using an ApplicationContextInitializer earlier. Invoking the http://<host>:<port>/actuator/health URL will return the internet status as in the following:

{
"status":"UP",
"details":{
"internet":{  
"status":"UP"
},
"diskSpace":{
"status":"UP",
"details":{
"total":399268376576,
"free":232285409280,
"threshold":10485760
}
}
}
}

HTTP was invented by Tim Berners-Lee in 1989 while he was working at CERN. It was designed as a way to share scientific findings among coworkers and is almost three decades old. When HTTP was invented, it was never intended to be the backbone of today's low-latency, high-traffic web, used by millions if not billions of people. So HTTP 1-and HTTP 1.1-based web applications had to have a lot of workarounds to cater to the high demands of the modern web. The following are some of those workarounds:

But HTTP/2 is designed from the ground up to tackle these pain points. Compared to HTTP 1.x, HTTP/2 doesn't use text to communicate between the client and server. It uses binary data frames, which makes it much more efficient and reduces the text-to-binary and binary-to-text conversion overhead in the servers. Furthermore, it has the following features introduced:

Spring Boot 2 supports HTTP/2 out of the box for server Undertow, and, with minor dependencies at https://docs.spring.io/spring-boot/docs/2.0.x-SNAPSHOT/reference/htmlsingle/#howto-configure-http2, also supports Tomcat and Jetty servers.  But Spring Boot 2 doesn't support the clear text version of HTTP/2, so Secure Socket Layer (SSL) is a must. It requires the following dependencies in pom.xml :

<dependencies>
   <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
      <exclusions>
         <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
         </exclusion>
      </exclusions>
   </dependency>

   <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-undertow</artifactId>
   </dependency>
   ...
</dependencies>

The configuration properties in application.yml configure both SSL and HTTP/2:

 server:
port: 8443
ssl:
key-store: keystore.p12
key-store-password: sslcert123
keyStoreType: PKCS12
keyAlias: sslcert

http2:
enabled: true

In this configuration SSL key-store, key-store-password, keyStoreType, and keyAlias are configured along with the port for HTTPs. The key was generated using keytool, which is a utility shipped with the JDK release with the following command, and fills in the necessary details when prompted by the utility tool:

$ keytool -genkey -alias sslcert -storetype PKCS12 -keyalg RSA -keysize 2048 -keystore keystore.p12 -validity 3650

Now when the https://<localhost>:8443/actuator/custom URL is accessed it will be served over HTTP/2.

Spring Boot 2.0 has introduced updated support for Spring Security with Spring Framework 5.0 and Reactive support for Spring Security, providing simplified default configurations and ease of customization for Spring Security. As opposed to having multiple auto-configurations for Spring Security, Spring Boot 2.0 has introduced a single behavior that can be overridden easily and can be customized easily with a WebSecurityConfigurerAdapter such as the following:

@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {

@Override
protected void configure(HttpSecurity http) throws Exception {
 http.httpBasic().and()
 .authorizeRequests()
 .requestMatchers(EndpointRequest.to("info", "health")).permitAll()
 .requestMatchers(EndpointRequest.toAnyEndpoint()).hasRole("SYSTEM")
 .antMatchers("/**").hasRole("USER");

}

@Override
protected void configure(AuthenticationManagerBuilder
 auth) throws Exception {
 auth.inMemoryAuthentication()
 .passwordEncoder(new 
 MessageDigestPasswordEncoder("SHA-256"))
 .withUser("user")
 .password("5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8")
 .roles("USER")
 .and()
 .withUser("sysuser")
 .password("5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8")
 .roles("SYSTEM");
}

}

One thing to note here is the introduction of the EndpointRequest helper class, which makes it easier to protect endpoints.

Spring Boot 2.0 doesn't support Java 6 or Java 7, which are still widely used in many production environments. So the first thing that needs to be done is to upgrade both development environments and runtime environments to at least Java 8 or above. 

java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException

<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>2.3.0</version>
</dependency>

Spring Boot 2.0 by default uses and supports Spring Framework 5.0. Thus, any change to it will affect migration to Spring Boot 2.0. Some notable changes are explained in the following topics.

A lot of configuration properties have been renamed/replaced from Spring Boot 1.x to Spring Boot 2.0. So these changes must be incorporated in the application.yml/application.properties file to do a successful migration. To ease this process, Spring Boot has released the spring-boot-properties-migrator properties migrator, which can be used in the Maven configuration as follows:

<dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-properties-migrator</artifactId>
        <scope>runtime</scope>
</dependency>

When this dependency is used, it will analyze the application environment, print out any diagnostics at startup, and even temporarily migrate properties at runtime.

With the introduction of Reactive Web Programming out of the box in Spring Boot 2.0, there needs to be a differentiation between properties for a servlet stack and properties for a reactive stack, so that previous properties such as server.*, which was related to the server ServletContext path, is not changed toserver.servlet.* , avoiding verbosity in property naming. 

In Spring Boot 2.0 the file extension for the mustache template engine has been changed from .html to .mustache. With the spring.mustache.suffix configuration property this behavior can be overridden if required.

The following changes have been introduced in the Spring Boot Actuator configuration properties in Spring Boot 2.0:

These changes have the potential to break existing code, and so must be changed accordingly when migrating.

Now, the /actuator path contains all Spring Boot Actuator-related endpoints. In order to get the previous version's behavior, the management.endpoints.web.base-path=/ configuration property needs to be set. Another change is the addition of a new purpose formanagement.server.servlet.context-path, which is the counterpart of server.servlet.context-path related to Spring Boot Actuator endpoints.

As an example, if management.server.servlet.context-path=/actuator is set, along with management.endpoints.web.base-path=/application, then the endpoints will be accessible under the /actuator/application/<endpoint> path.

The following Spring Boot Actuator endpoints have been changed:

Applications depending on these endpoints need to be changed to use the renamed endpoints.

EmbeddedServletContainer is changed to WebServer. Also, the org.springframework.boot.context.embedded package is refactored to org.springframework.boot.web.embedded. If TomcatEmbeddedServletContainerFactory was used to configure an embedded Tomcat with a custom port in an application as in the following, then it will need to be changed:

@Bean
public EmbeddedServletContainerFactory servletContainer() {
 TomcatEmbeddedServletContainerFactory tomcat = new TomcatEmbeddedServletContainerFactory();
 Connector connector = new Connector("org.apache.coyote.http11.Http11NioProtocol");
 connector.setScheme("http");
 connector.setPort(9090); 
 tomcat.addAdditionalTomcatConnectors(connector);
 return tomcat;
}

It must be changed to use TomcatServletWebServerFactory instead, as in the following:

@Bean
public TomcatServletWebServerFactory webServer() {
    TomcatServletWebServerFactory tomcat = new 
    TomcatServletWebServerFactory(9090);
    return tomcat;
}

The default behavior of map extensions such as .json and .xml to existing controller request mappings has changed in Spring Boot 2.0. Consider the following URL mapping:

@GetMapping("/users")

If it is expected to cater to the /users.json URL in a Spring Boot 1.x application, then it won't be supported in Spring Boot 2.0. This means new mappings need to be added as necessary.

The default dispatcher type for the servlet filter in Spring Boot 2.0 is DispatcherType.REQUEST. This is changed to be in line with the default in the servlet specification. If other dispatcher types are required then a FilterRegistrationBean must be used to register the filter.

Spring Boot 1.x had the transitive dependencyspring-boot-starter-web whenever one of the following template engine starters was used:

This was done because Spring Web MVC was running on top of the Servlet API, which is the only web application framework that was available at that time.

Now, with the introduction of the Spring Reactive Web starter spring-boot-starter-webflux, which is completely independent of the Servlet API, transitive dependencies from those template engine starters have been removed. This means that, when a template engine starter dependency is added, a developer needs to manually add a dependency to either Spring Web MVC starter or Spring Web Flux starter based on the requirement.

Spring Boot 2.0 uses CGLIB as the default proxying strategy including for aspect-oriented programming (AOP). If proxy based proxying is required, the following configuration property needs to be set:

spring.aop.proxy-target-class=false.

With Spring Boot 2.0, the spring.config.location configuration will no longer append to the list of configurations; instead, it will replace it. So, if append logic is required, then spring.config.additional-location must be used.

With Spring Boot 2.0, Jackson's configuration was modified to write JSR-310 dates as ISO-8601 strings. For its previous behavior, the property spring.jackson.serialization.write-dates-as-timestamps=true needs to be set.

The separate security auto-configuration for actuators has been removed in Spring Boot 2.0; thus, management.security.* properties are no longer supported. The endpoints.<id>.sensitive flag for each endpoint is no longer available, and if an application is dependent on this behavior then it must use a custom configuration for Spring Security to permit or restrict access to those endpoints. 

With Spring Boot 2.0, the default connection pool for JPA has been changed from Tomcat to HikariCP. Thus it is no longer required to use the configuration property spring.datasource.type as an override to use HikariCP. Using the following dependency will by default use HikariCP:

<dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

With Spring Boot 2.0, the default basic DataSource initialization is only enabled for embedded databases and will be disabled as soon as a production database is used. The configuration property spring.datasource.initialization-mode (with values always or never), which replaces the old spring.datasource.initialize configuration property, can be used for more control. 

The default behavior for embedded databases used with a schema manager such as Liquibase, Flyway, and so on will be dropping existing tables and creating a new one, which is similar to create-drop for the configuration property spring.jpa.hibernate.ddl-auto .If no schema manager is used then the default behavior is to do nothing, which is similar to setting none for the aforementioned configuration property.

The following test annotations are no longer supported for Mockito 1.x:

If testing needs to be done using the aforementioned annotations then Spring Boot 2.0 spring-boot-starter-test must be used or Mockito 2.x must be used explicitly. 

There are some Spring Security-related changes made for Spring Boot 2.0's release, which need to be incorporated when migrating. Some of the most notable ones are explained in the following sections.

Some features that were available in Spring Boot 1.x but are no longer supported in Spring Boot 2.0 are as follows: