Salut, c'est @chan_kaku Dans l'article précédent ici, j'ai parlé de passer de la série Spring Boot 1.5 à la série 2.1. Cette fois, je voudrais évoquer les difficultés que j'ai rencontrées lorsque j'ai effectué une migration à grande échelle suite à la migration précédente.
Pour le service cible que j'ai écrit dans l'article précédent, j'ai choisi celui avec le moins de bibliothèques dépendantes possible afin de connaître à l'avance les points auxquels je pourrais être accro en tant qu'étape préliminaire au service qui est la cible de cette migration. C'était. Le service cible dépend cette fois de Spring Cloud, etc., il y avait donc de nombreux points addictifs différents de la fois précédente, j'ai donc décidé de l'écrire à nouveau.
--SérieGradle3 → Série Gradle5 --Spring Boot 1.5 series → Spring Boot 2.1 series --Mise à niveau d'autres bibliothèques dépendantes
Quant à ce que j'ai fait, j'ai l'impression qu'il y a beaucoup de choses que je porte au début. Dans cet article, j'écrirai les différences par rapport au précédent.
La dernière fois, la mise à niveau de la version de Spring Boot elle-même n'a été résolue qu'en ajoutant ʻio.spring.dependency-management`. Cependant, Spring Cloud a été le changement majeur de la série 1.5 à la série 2.1.
Feign Client était l'un des Spring Clouds qui a connu un changement radical. En premier lieu, la configuration du package a changé comme suit
- import org.springframework.cloud.netflix.feign.FeignClient;
+ import org.springframework.cloud.openfeign.FeignClient;
À l'origine, il utilisait le client Feign de Netflix, mais il a été remplacé par le client Feign d'Open Feign. Parallèlement à cela, l'interface a changé et il est nécessaire de corriger cette zone. (Pour FeignClientException)
Puisqu'il s'agissait d'un composant qui se connecte à des services externes, nous l'avons soigneusement testé ici.
Le prochain changement concerne la source de données par défaut dans Spring Boot. Tomcat JDBC a été utilisé par défaut dans la série 1.x. Cependant, HikariCP est utilisé par défaut à partir de la série 2.x. Maintenant que ce Hikari CP est utilisé, une erreur est survenue. Une erreur s'est produite car la version de HikariCP utilisée dans la série SpringBoot 2.x et la version de HikariCP utilisée dans d'autres bibliothèques dépendantes sont différentes. L'histoire ici a également été mentionnée dans [numéro] de Spring Boot (https://github.com/spring-projects/spring-boot/issues/16656), alors pourquoi ne pas y jeter un coup d'œil?
Cette fois, je savais que l'erreur était due à une version différente de HikariCP, alors j'ai deviné que la version de Spring JDBC était différente quelque part. Cependant, je ne savais pas quelle version de Spring JDBC était la plus ancienne, j'ai donc utilisé la commande Gradle dependencies.
Cette tâche est une commande qui peut être exécutée avec gradle sans ajouter de dépendance, et peut être exécutée comme suit
./gradlew dependencies
Vous pouvez vérifier l'arborescence des dépendances en exécutant cette commande! J'ai regardé l'arborescence de dépendances générée par cette commande et j'ai trouvé une version plus ancienne de la bibliothèque, j'ai donc pu résoudre l'erreur en excluant Spring JDBC de là. Plus précisément, la version de Spring JDBC dont dépendait la dernière version de ʻorg.seasar.doma.boot: doma-spring-boot-starter` était ancienne, donc je l'ai résolue en excluant Spring JDBC comme suit.
build.gradle
implementation("org.seasar.doma.boot:doma-spring-boot-starter:1.1.1") {
exclude group: "org.springframework.boot", module: "spring-boot-starter-jdbc"
}
Avec la solution de contournement ci-dessus, vous pouvez maintenant exécuter le fichier jar. Cependant, lorsque j'exécute bootRun à partir de gradle, j'obtiens l'erreur suivante:
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
Dans ce projet, classPath est réécrit avec l'option bootRun, mais cela est réécrit car il semble qu'une erreur se produira dans Windows lorsqu'il existe de nombreuses dépendances de ce projet. Autour d'ici a plus de détails, alors jetez un œil! Il semble que bootRun ne soit pas possible en raison de cette réécriture de classPath, mais je ne connais pas la solution et elle est actuellement sous enquête (juillet 2019). Je l'ajouterai dès que je trouverai une solution!
Lors de la dénomination du jar, jusqu'à présent, il était décrit comme suit dans l'option jar de build.gradle
build.gradle
jar {
archiveBaseName = "hoge"
archiveFileName = "${archiveBaseName}.jar"
version = "1.0.0"
}
Il n'y a pas de problème lors de la création d'un fichier jar localement, mais lors de la création d'un fichier jar avec CI, le nom racine du projet peut être différent, et cette ʻarchiveBase.jar` n'est pas devenue un phénomène. Par conséquent, lorsque je voulais utiliser le nom de fichier jar spécifié dans l'environnement CI, la solution de contournement que j'ai prise cette fois était d'ajouter settings.gradle comme suit.
settings.gradle
rootProject.name = 'hoge'
En ajoutant rootProject.name à settings.gradle, le nom du fichier jar ne changera pas même dans l'environnement CI.
La série SpringBoot 1.5.x sera EOL en août 2019, donc si vous ne l'avez pas encore supportée, vous devriez vraiment vous dépêcher, alors j'espère que cet article sera utile pour tout le monde!
Recommended Posts