The story of raising Spring Boot from 1.5 series to 2.1 series part2

Introduction

Hi, this is @chan_kaku In the previous article here, I talked about raising from Spring Boot 1.5 series to 2.1 series. This time, I would like to mention the difficulties that I had when I made a full-scale migration following the previous migration.

Why are you writing similar articles

For the target service I wrote in the previous article, I chose the one with as few dependent libraries as possible in order to know in advance the points that I might be addicted to as a preliminary step to the service to be migrated this time. It was. The service targeted this time depends on Spring Cloud etc., so there were many addictive points that were different from the previous time, so I decided to write it again.

What I did (overview)

--Gradle3 series → Gradle5 series --Spring Boot 1.5 series → Spring Boot 2.1 series --Upgrade of other dependent libraries

As for what I did, I feel that there are many things that I wear at the beginning. In this article, I will write the differences from the previous one.

SpringBoot 1.5 series → Spring Boot 2.1 series

Last time, the version upgrade of Spring Boot itself was solved only by adding ʻio.spring.dependency-management`. However, the place where there was a big change from this 1.5 series to 2.1 series was Spring Cloud.

Change 1

Feign Client was the one that had a breaking change in Spring Cloud. In the first place, the package configuration has changed as follows

- import org.springframework.cloud.netflix.feign.FeignClient;
+ import org.springframework.cloud.openfeign.FeignClient;

Originally it used Netflix's Feign Client, but it has changed to Open Feign's Feign Client. Along with this, the interface has changed, and it is necessary to correct that area. (Per FeignClientException)

Since it was a part that connects with external services, we carefully tested it here.

Change 2

The next change is about the default data source in Spring Boot. Tomcat JDBC was used by default in 1.x series. However, HikariCP is used by default from 2.x series. Now that this Hikari CP is used, an error has come out. An error occurred because the version of HikariCP used in SpringBoot 2.x series and the version of HikariCP used in other dependent libraries are different. The story around here was also mentioned in [issue] of Spring Boot (https://github.com/spring-projects/spring-boot/issues/16656), so why not take a look?

approach

This time, I knew that the error was due to a different version of HikariCP, so I guessed that the version of Spring JDBC was different somewhere. However, I didn't know which Spring JDBC version was older, so I used the Gradle command dependencies. This task is a command that can be executed with gradle without adding a dependency, and can be executed as follows

./gradlew dependencies

You can check the dependency tree by executing this command! I looked at the dependency tree generated by this command and found an older version of the library, so I was able to resolve the error by exclude Spring JDBC from there. Specifically, the version of Spring JDBC that the latest version of ʻorg.seasar.doma.boot: doma-spring-boot-starter` depended on was old, so I solved it by excluding Spring JDBC as follows.

build.gradle

implementation("org.seasar.doma.boot:doma-spring-boot-starter:1.1.1") {
        exclude group: "org.springframework.boot", module: "spring-boot-starter-jdbc"
}

Things that haven't been solved yet

With the above workaround, you can now execute the jar. However, when I run bootRun from gradle, I get the following error:

Exception in thread "main" java.lang.NoClassDefFoundError: org/springframework/boot/SpringApplication
        at jp.furyu.hoge.api.HogeApiApplication.main(HogeApiApplication.java:14)
Caused by: java.lang.ClassNotFoundException: org.springframework.boot.SpringApplication
        at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        ... 1 more

In this project, the classPath is rewritten with the bootRun option, but this is rewritten because it seems that an error will occur in windows when there are many dependencies of this project. Around here has more details, so please have a look! It seems that bootRun is not possible due to this rewriting of classPath, but I do not know the solution and it is currently under investigation (July 2019). I will add it as soon as I find a solution!

Postscript (2019/8/8)

When naming the jar, until now it was described as follows in the jar option of build.gradle

build.gradle

jar {
    archiveBaseName = "hoge"
    archiveFileName = "${archiveBaseName}.jar"
    version = "1.0.0"
}

There is no problem when making a jar locally, but when making a jar with CI, the root name of the project may be different, and this phenomenon that it does not become ʻarchiveBase.jar` occurred. So, when I wanted to name the jar specified in the CI environment, the workaround I took this time was to add settings.gradle as follows.

settings.gradle

rootProject.name = 'hoge'

By adding rootProject.name to settings.gradle, the name of the jar will not change even in the CI environment.

Finally

SpringBoot 1.5.x series will be EOL in August 2019, so if you haven't supported it yet, you should really hurry, so I hope this article will be helpful for everyone!