Eine kurze Analyse des Spring-Boot-Lastmoduls im Federschuh

1. Vorwort

Unter normalen Umständen kann der Klassenloader die Datei *.class -Datei nur im aktuellen Verzeichnis oder in der Dateiklasse im Glas finden. Um die Ressourcen im verschachtelten Glas zu laden, werden die Klassendatei im verschachtelten Glas und die Klassendatei der Anwendung in ein Glas verpackt, so dass es kein verschachteltes Glas gibt. Dabei können Sie jedoch nicht genau wissen, worauf die Anwendung abhängt und welche Anwendungen selbst sind. Darüber hinaus können der Klasseninhalt in mehreren Gläsern unterschiedlich sein, aber die Dateinamen sind gleich. Spring-Boot-Lader im Springboot wurde geboren, um dieses Problem anmutig zu lösen.

Mit dem Spring-Boot-Loader-Modul können wir Java-Jar Archive.jar verwenden, um JAR- oder Kriegsdateien mit verschachtelten Abhängigkeiten auszuführen. Es bietet drei Arten von Launchern (Jarlauncher, Warlauncher und PropertieSlauncher). Der Zweck dieser Klassenstauner besteht darin, in der Glas verschachtelte Ressourcen zu laden (z. B. Klassendateien, Konfigurationsdateien usw.). [Jar | Krieg] Der Launcher sucht im LIB -Verzeichnis des aktuellen JAR fixiert nach Ressourcen in verschachtelten JAR -Dateien.

2. Die JAR-Verzeichnisstruktur des Spring-Boot-Lader-Moduls

Das JAR -Dateiformat im Springboot ist wie folgt festgelegt:

 archive.jar | +-Meta-inf (1) | +-Manifest.mf +-org (2) | +-springframework | +-Boot | +-Loader | +-<Spring-Boot-Loader-Klassen> +-com (3) | +-MyCompany | + Projekt | +-YoUclasses.class +-lib (4) +-Diffendenz1.jar +-Diffendenz2.jar

• Struktur (1) Manifest.mf Dateispeicherspeicherort in der JAR -Datei
• Struktur (2) Platzierung der Klassen, die durch Spring-Boot-Lader selbst erforderlich ist
• Struktur (3) wo die Datei in der Anwendung selbst platziert werden soll
• Struktur (4) Das anwendungsabhängige Glas ist im LIB-Verzeichnis festgelegt.

Wie lädt Spring-Boot-Ressourcen gemäß dieser Struktur aus?

• Bei der Verpackung wird die JAR-Datei zunächst mit dem Spring-Boot-Maven-Plugin-Plugin umgestellt, und das meta-inf/Manifest.mf wird festgelegt.

 Hauptklasse: org.springframework.boot.loader.jarlauncher Startklasse: com.mycompany.project.myapplication

Und kopieren Sie die Klassendatei im Spring-Boot-Lader-Paket in die Struktur (2) und kopieren Sie die Anwendungsabhängigkeit in (4) Kopieren Sie die Anwendungsklasse in (3).

• Wenn der Java -Jar Archive.jar Runtime Launcher die Jarlauncher -Klasse lädt und die Hauptfunktion ausführt. Jarlauncher befasst sich hauptsächlich mit dem Bau eines geeigneten URLCASSELALE -Laders, um die Hauptmethode unserer Anwendung (MyApplication) aufzurufen.

3. Analyse des Spring-Boot-Maven-Plugin-Plug-in-Verpackungsprozesses

Hinweis: Hier müssen wir darüber nachdenken, warum wir die Klasse kopieren müssen, um sie zu strukturieren (2), die in die Spring-Boot-Lader eingebracht werden sollen.

4. Jarlauncher Ausführungsprozessanalyse

Nach dem Lesen dieses Vorgangs werden wir die im dritten Abschnitt verbleibenden Probleme analysieren. Zum Beispiel verwendet der Flowdiagramm zuerst AppClassloader, um die Jarlaunchern -Klasse zu laden und die LOWNEDURLCLASSELADER -Klasse zu erstellen. Der StartedurlClassloader gehört zum Paket für Spring-Boot-Loader.jar, und der AppClassloader ist ein gewöhnlicher Loader, der die Dateien nicht im verschachtelten Glas laden kann. Wenn Spring-Boot-Loader.jar im LIB-Verzeichnis platziert ist, findet der AppClassloader den StartedurlClassloader nicht. Also beim Packen

Kopieren Sie die Klasse in Struktur (2), die in Lib in die Spring-Boot-Lader.

5. Zusammenfassung

Das Spring-Boot-Lastmodul implementiert elegant die Belastung von verschachtelten Glasressourcen durch eine benutzerdefinierte JAR-Paketstruktur. Durch Zurücksetzen der Start -Klasse und der Organisations -Jar -Struktur während des Verpackung und der Festlegung eines benutzerdefinierten Laders zur Laufzeit, um verschachtelte JAR -Ressourcen zu erreichen.