Memorandum of understanding when Spring Boot 1.5.10 → Spring Boot 2.0.0

Introduction

The WEB application under construction was Spring Boot 1.5.10, but since 2.0.0 has been released, let's update it. It is a memorandum of what I did at that time. Note) Only what is required for the WEB application under construction is described.

• Spring Web MVC
• Spring Security
• Thymeleaf
• Gradle

(4/18 postscript) Since a vulnerability was found in version 5.0.4 of Spring Framework used in 2.0.0, it has been upgraded to 2.0.1. For more information (https://www.jpcert.or.jp/at/2018/at180014.html)

Rough changes

Spring4　→　Spring5

The following article was very helpful for the changes in Spring5. Reference) Summary of major changes in Spring Framework 5.0

** Java 8 or above required **

Java was originally 8 so it had no effect.

Thymeleaf2 → Thymeleaf3

It may have been the most influential part of the app I was making.

About what I did specifically

For the time being, I set the Spring Boot version of gradle to 2.0.0 and built it to wild: smirk: without modifying anything. I got an error in haste, so I will look at the procedure properly and solve it in order.

Good boys should read Spring Boot 2.0's Migrate Guide carefully and read the room. Brighten up and try away.

1. Upgrade of gradlew

4.x or above is required. For some reason, it was 2.x gradlew, so naturally it will be moss there. (The criminal is me)

Update the wrapper task version.

build.gradle

task wrapper(type: Wrapper) {
    gradleVersion = '4.6' //Version 4.Set to x or higher
}

Add a wrapper task to build.gradle and run the command `gradle wrapper` to make it gradlew version 4.x or higher. You can now use gradlew to build your SpringBoot 2.0.0 application.

Reference) Spring-Boot-2.0-Release-Notes # gradle-plugin

2. Specification change of spring-boot-gradle-plugin

apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management' // <-- add this to your build.gradle

With the version upgrade, it seems that the dependency management plugin is no longer applied automatically. You need to read it explicitly, so follow the instructions to add a line.

Reference) [Spring-Boot-2.0-Migration-Guide # spring-boot-gradle-plugin](https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide # spring-boot-gradle-plugin)

3. Specification change of application.yml (propeties)

There seems to be a check tool called spring-boot-properties-migrator.

Temporarily added to build.gradle dependency.

gradle build and start Spring Boot Application. Then, an unfamiliar message appears on the console. It will tell you what properties have changed names and what have disappeared.

Reference) [Spring-Boot-2.0-Migration-Guide # before-you-start](https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide#before- you-start)

4. hibernate validator The Hibernate validator NotEmpty annotation has been deprecated. It didn't affect me because I didn't use it, but it seems that annotations such as NotBlank, Email, and ModCheck are also deprecated in addition to NotEmpty.

use the standard NotEmpty constraint instead

Because there is, I corrected it like that.

Reference) Hibernate Validator --Deprecated API

5. Spring Mvc JavaConfig

WebMvcConfigurerAdapter has been deprecated.

Reference) Spring-javadoc WebMvcConfigurerAdapter.java

as of 5.0 WebMvcConfigurer has default methods (made possible by a Java 8 baseline) and can be implemented directly without the need for this adapter.

It says that the WebMvcConfigurer interface now has a default method so you don't need an adapter anymore.

** WebMvcConfig.java before change **

WebMvcConfig before change.java

@Configuration
public class WebMvcConfig extends WebMvcConfigurerAdapter
{
    //Abbreviation
}

** Modified WebMvcConfig.java **

WebMvcConfig after change.java

@Configuration
public class WebMvcConfig implements WebMvcConfigurer
{
    //Abbreviation
}

6. SpringSecurity

Reference) https://docs.spring.io/spring-security/site/docs/5.0.3.RELEASE/reference/htmlsingle/ Reference) https://spring.io/blog/2017/09/15/security-changes-in-spring-boot-2-0-m4 TODO: Summarize the contents ... maybe.

7. Various Thymeleaf

JavaConfig I didn't make it, so it didn't affect me, but please note that there seems to be a change for those who make it.

It is described in detail in the section 2. Configuration changes of the migration guide below. Reference) Thymeleaf 3 ten-minute migration guide

Dialect

This has changed a lot and the old one was error Zammai: open_hands_tone1:. I made a Dialect that makes the line feed code a ```
tag, so I recreated it referring to the following.

Reference) Say Hello! Extending Thymeleaf in 5 minutes Reference) Say Hello Again! Extending Thymeleaf even more in another 5 minutes

TemplateMode In the case of Thymeleaf2, the parser is XML-based and the check is very strict, so after setting TemplateMode.LEGACYHTML5, nekoHTML was used as the HTML parser, but it is recommended to use TemplateMode.HTML in Thymeleaf3. It seems that it has been done, so I changed it. (TemplateMode.LEGACYHTML5 has been deprecated.) Bye bye: cat:

The second difference is that the template mode has a value of TemplateMode.HTML. Template modes are not strings anymore and the possible values are a bit different from Thymeleaf 2. We will discuss it in a minute.

Reference) Thymeleaf 3 ten-minute migration guide

Remove th: inline syntax

It does not cause an error, but the migration guide stated as follows. I didn't use th: inline this time, so it wasn't the target of correction, but be careful not to use it accidentally.

The only change we recommend doing to your templates is removing any th:inline="text" attributes you might have, because they are not needed anymore in order to have output inlined expressions in HTML or XML templates. And it’s just a recommendation — templates will work anyway. But you will benefit from some extra processing performance if you remove those.

A fix is recommended.

Thymeleaf2

<tr th:inline="text" th:each="user : ${users}">
    <td>[[$(user.id)]]</td>
    <td>[[$(user.name)]]</td>
</tr>

Reference) [Thymeleaf2- 12. Inline processing](https://www.thymeleaf.org/doc/tutorials/2.1/usingthymeleaf_ja.html#%E3%82%A4%E3%83%B3%E3%83%A9% E3% 82% A4% E3% 83% B3% E5% 87% A6% E7% 90% 86)

Thymeleaf3

<tr th:each="user : ${users}">
    <td>[[$(user.id)]]</td>
    <td>[[$(user.name)]]</td>
</tr>

Reference) Thymeleaf3 --12 Inlining

• The Japanese document seemed to be the same as the explanation of the 2nd system, so I linked it to the English document.

8. Connection pool (additional note)

The default connection pool was changed from Tomcat JDBC Connection Pool to HikariCP. It was leaked because it was not the time when the source affected by the implementation difference was migrated, but I will add it.

The Migration-Guide says that those who have added dependencies to use HikariCP no longer need to write them.

Reference) [Spring-Boot-2.0-Migration-Guide --working-with-sql-databases] (https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide#working-with-sql-databases)

It was also written in the Spring Boot documentation like this.

Production database connections can also be auto-configured by using a pooling DataSource. Spring Boot uses the following algorithm for choosing a specific implementation: 1.We prefer HikariCP for its performance and concurrency. If HikariCP is available, we always choose it. 2.Otherwise, if the Tomcat pooling DataSource is available, we use it. 3.If neither HikariCP nor the Tomcat pooling datasource are available and if Commons DBCP2 is available, we use it.

Reference) Spring-Boot Documents --boot-features-connect-to-production-database

spring.datasource.tomcat.max-wait=10000
spring.datasource.tomcat.max-active=50
spring.datasource.tomcat.test-on-borrow=true

I wonder if it will have an effect if I define a property with a prefix like this. HikariCP setting is `spring.datasource.hikari. *`.

end