[JAVA] Die Geschichte der Erhöhung von Spring Boot von 1.5 auf 2.1 Serie Teil2

Einführung

Hallo, das ist @chan_kaku Im vorherigen Artikel hier habe ich über das Erhöhen von der Spring Boot 1.5-Serie auf die 2.1-Serie gesprochen. Dieses Mal möchte ich die Schwierigkeiten erwähnen, die ich hatte, als ich nach der vorherigen Migration eine vollständige Migration durchführte.

Warum schreibst du ähnliche Artikel?

Für den Zieldienst, den ich im vorherigen Artikel geschrieben habe, habe ich den mit so wenigen abhängigen Bibliotheken wie möglich ausgewählt, um im Voraus zu wissen, auf welche Punkte ich als vorläufiger Schritt zu dem Dienst, der das Ziel dieser Migration ist, süchtig werden könnte. Es war. Der Zieldienst hängt diesmal von Spring Cloud usw. ab, daher gab es viele Suchtpunkte, die sich von der vorherigen Zeit unterschieden. Deshalb habe ich beschlossen, ihn erneut zu schreiben.

Was ich getan habe (Übersicht)

--Gradle3-Serie → Gradle5-Serie --Spring Boot 1.5-Serie → Spring Boot 2.1-Serie

• Upgrade anderer abhängiger Bibliotheken

Was ich getan habe, ich habe das Gefühl, dass es viele Dinge gibt, die ich am Anfang trage. In diesem Artikel werde ich die Unterschiede zum vorherigen schreiben.

SpringBoot 1.5-Serie → Spring Boot 2.1-Serie

Das letzte Mal wurde das Versions-Upgrade von Spring Boot selbst nur durch Hinzufügen von "io.spring.dependency-management" gelöst. Spring Cloud war jedoch die wichtigste Änderung von der 1.5-Serie zur 2.1-Serie.

Änderung 1

Feign Client war eine der Frühlingswolken, die eine bahnbrechende Veränderung hatten. Erstens hat sich die Paketkonfiguration wie folgt geändert

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

Ursprünglich wurde der Feign-Client von Netflix verwendet, aber er wurde in den Feign-Client von Open Feign geändert. Gleichzeitig hat sich die Schnittstelle geändert, und dieser Bereich muss korrigiert werden. (Per FeignClientException)

Da es sich um einen Teil handelt, der mit externen Diensten verbunden ist, haben wir ihn hier sorgfältig getestet.

Änderung 2

Die nächste Änderung betrifft die Standarddatenquelle in Spring Boot. Tomcat JDBC wurde standardmäßig in der 1.x-Serie verwendet. HikariCP wird jedoch standardmäßig aus der 2.x-Serie verwendet. Nachdem dieser Hikari CP verwendet wurde, ist ein Fehler aufgetreten. Ein Fehler ist aufgetreten, weil die in SpringBoot 2.x-Serie verwendete Version von HikariCP und die in anderen abhängigen Bibliotheken verwendete Version von HikariCP unterschiedlich sind. Die Geschichte hier wurde auch in [Ausgabe] von Spring Boot (https://github.com/spring-projects/spring-boot/issues/16656) erwähnt. Warum also nicht einen Blick darauf werfen?

Ansatz

Dieses Mal wusste ich, dass der Fehler auf eine andere Version von HikariCP zurückzuführen war, daher vermutete ich, dass die Version von Spring JDBC irgendwo anders war. Da ich jedoch nicht wusste, welche Spring JDBC-Version älter ist, habe ich den Gradle-Befehl "Abhängigkeiten" verwendet. Diese Aufgabe ist ein Befehl, der mit gradle ausgeführt werden kann, ohne eine Abhängigkeit hinzuzufügen, und wie folgt ausgeführt werden kann

./gradlew dependencies

Sie können den Abhängigkeitsbaum überprüfen, indem Sie diesen Befehl ausführen! Ich habe mir den von diesem Befehl generierten Abhängigkeitsbaum angesehen und eine ältere Version der Bibliothek gefunden, sodass ich den Fehler beheben konnte, indem ich Spring JDBC von dort ausgeschlossen habe. Insbesondere die Version von Spring JDBC, von der die neueste Version von org.seasar.doma.boot: doma-spring-boot-Starter abhing, war alt, daher habe ich Spring JDBC wie folgt ausgeschlossen.

build.gradle

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

Dinge, die noch nicht gelöst wurden

Mit der obigen Problemumgehung können Sie jetzt das Glas ausführen. Wenn ich jedoch bootRun von gradle aus starte, wird der folgende Fehler angezeigt:

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 diesem Projekt wird classPath mit der Option bootRun neu geschrieben. Dies wird jedoch neu geschrieben, da in Windows anscheinend ein Fehler auftritt, wenn viele Abhängigkeiten von diesem Projekt bestehen. Hier in der Nähe enthält weitere Details. Schauen Sie also bitte vorbei! Es scheint, dass bootRun aufgrund dieses Umschreibens von classPath nicht möglich ist, aber ich kenne die Lösung nicht und sie wird derzeit untersucht (Juli 2019). Ich werde es hinzufügen, sobald ich eine Lösung gefunden habe!

Nachtrag (08.08.2019)

Bei der Benennung des JARs wurde es bisher in der JAR-Option von build.gradle wie folgt beschrieben

build.gradle

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

Es gibt kein Problem, wenn ein JAR lokal erstellt wird. Wenn Sie jedoch ein JAR mit CI erstellen, kann der Stammname des Projekts unterschiedlich sein, und dieses Phänomen, dass es nicht zu "archiveBase.jar" wird, ist aufgetreten. Wenn ich den angegebenen JAR-Namen in der CI-Umgebung verwenden wollte, bestand die Problemumgehung dieses Mal darin, settings.gradle wie folgt hinzuzufügen.

settings.gradle

rootProject.name = 'hoge'

Durch Hinzufügen von "rootProject.name" zu settings.gradle ändert sich der Name des JARs auch in der CI-Umgebung nicht.

Schließlich

Die SpringBoot 1.5.x-Serie wird im August 2019 EOL sein. Wenn Sie sie also noch nicht unterstützt haben, sollten Sie sich wirklich beeilen. Ich hoffe, dieser Artikel ist für alle hilfreich!