Zurück in die Zukunft: Ausführen von Spring Boot 2 in GlassFish 4 mit Java 8

Verleugnung, Wut, Verhandeln, Depression …

Jeder Entwickler träumt davon, mit modernen Technologien zu arbeiten und auf dem neuesten Stand zu bleiben. Tatsächlich ist es fast unmöglich, eine starke Einstellungsstrategie rund um veraltete, überholte und oft ineffektive und sogar totgeborene Technologien aufzubauen.

Allerdings ist das Leben komplex und nicht immer hängt alles von unseren Wünschen ab.

Möglicherweise wird Ihnen eine Beförderung angeboten und Sie werden in ein Projekt versetzt, bei dem sich die Technologien seit Jahren nicht geändert oder aktualisiert haben. Oder Sie landen einen Job bei Ihrem Traumunternehmen, dessen aktuelle Technologie Sie derzeit nicht besonders interessiert. Vielleicht haben Sie gerade Ihr Studium abgeschlossen und möchten unbedingt Ihre ersten Berufserfahrungen sammeln, oder Sie wurden von Ihrem vorherigen Job entlassen und müssen schnell etwas Neues finden, um finanzielle Schwierigkeiten zu vermeiden.

Es gibt auch ein anderes Szenario: Während des Vorstellungsgesprächs wird Ihnen gesagt, dass Sie zunächst mit dem aktuellen Stack arbeiten, in Zukunft aber reichlich Gelegenheit für Änderungen haben werden – vielleicht, möglicherweise, aber …

Annahme…

Aber seien wir ehrlich, das ist alles nur Philosophie. Ich stimme zu und schlage vor, wir analysieren einen realen Fall, der Ihnen auf Ihrem anspruchsvollen Karriereweg begegnen könnte.

Dies ist für alle Fans des JVM-Stacks, insbesondere für diejenigen, die das Spring Framework lieben. Lesen Sie bitte weiter.

Übrigens, warum sollten Sie eine Spring Boot -Anwendung überhaupt auf einem Anwendungsserver bereitstellen, wenn sie unabhängig ausgeführt werden kann? Schließlich ist das eine der herausragenden Funktionen von Spring Boot.

Dafür kann es mehrere Gründe geben:

1. Möglicherweise haben Sie die Infrastruktur für die Bereitstellung von Anwendungen bereits in GlassFish oder einem anderen EE-Anwendungsserver eingerichtet. In diesem Fall ist der EE-Anwendungsserver installiert, konfiguriert und wird vollständig unterstützt. Auch wenn die Anwendung unabhängig ausgeführt werden kann, wie dies bei Spring Boot der Fall ist, müssen Sie die Infrastruktur für die Bereitstellung und Laufzeit vorbereiten und warten.
2. Sie wissen, dass Sie nach einer Weile beginnen werden, den Anwendungsserver aufzugeben und daher beginnen, die Technologie, die Sie in Zukunft verwenden werden, im Voraus zu nutzen, mit der Möglichkeit, sie in der aktuellen Umgebung zu verwenden
3. Unterschiedliche Erfahrungen und Fachkenntnisse im Team
4. Experimente und Hypothesentests

Java 8

Java 8 wurde am 18. März 2014 veröffentlicht und brachte Meilensteinfunktionen , die wir bis heute nutzen.

Ich muss nicht weit gehen, um Beispiele zu finden. Hier sind nur einige davon:

• Lambda-Ausdrücke

• Stream-API

• Optionale Klasse

• Das java.time-Paket (Datums- und Uhrzeit-API)

• usw. usw.

  
  

Seitdem wurden bis heute ( 19.08.2024 ) drei LTS-Versionen veröffentlicht:

• Java SE 11(55) - 25. September 2018
• Java SE 17(61) - 14. September 2021
• Java SE 21(65) – 19. September 2023

Laut einer Studie von New Relic wird Java 8 immer noch in 28,8 % der aktuellen Projekte verwendet, was, wie Sie sicherlich zustimmen werden, nicht unerheblich ist. Obwohl sein Anteil von Jahr zu Jahr allmählich abnimmt, ist es sicherlich zu früh, diese Technologie völlig abzutun.

GlassFish 4.1.2

Laut der Eclipse GlassFish gewidmeten Project Eclipse-Website :

Eclipse GlassFish® ist ein vollständiger Anwendungsserver, der die Jakarta EE-Spezifikation implementiert. GlassFish enthält Implementierungen aller erforderlichen und optionalen Jakarta EE-APIs und erfüllt alle Jakarta EE TCKs. GlassFish enthält außerdem eine vollständige Administrationskonsole, Clustering-Unterstützung und andere auf Entwickler und Produktion ausgerichtete Tools und Funktionen.

Leider ist es nicht möglich, von dieser Website Versionen unter 5.1.0 herunterzuladen. Da wir uns jedoch für die Version unter 5.1.0 entschieden haben, müssen wir auf die Oracle-Website gehen, wo Sie im Downloadbereich mehrere frühere Versionen dieses Produkts finden. Seien Sie jedoch vorsichtig mit der Lizenz und verwenden Sie nichts aus diesem Ordner außerhalb Ihrer Sandbox.

Legen Sie die Verteilungsdatei einfach irgendwo auf Ihrem Computer ab, navigieren Sie zum bin Ordner und führen Sie den folgenden Befehl aus:

 ./asadmin start-domain --verbose

Warten Sie einen Moment und versuchen Sie , http://localhost:4848/ zu öffnen. Die Admin-Konsole sollte standardmäßig verfügbar sein und keine Anmeldeinformationen anfordern. Im linken Bereich finden Sie die Registerkarte „Anwendungen“. Wenn Sie darauf klicken, erhalten Sie Zugriff auf ein Menü, mit dem Sie Anwendungen bereitstellen, deinstallieren, aktivieren und deaktivieren können.

Das ist im Moment alles, was Sie über GlassFish wissen müssen, um zu versuchen, Ihre Anwendung dort bereitzustellen.

Spring Boot 2

Es ist wahrscheinlich ziemlich schwierig, in der Welt der Webentwicklung jemanden zu finden, der nicht mindestens einmal von diesem beliebten Framework gehört hat.

Spring Boot 2 wurde im Jahr 2021 veröffentlicht und erfordert mindestens Java 8, im Gegensatz zu Version 3, die mindestens Java 17 erfordert .

Um die neuesten Funktionen, Sicherheitspatches und einige Optimierungen nutzen zu können, müssen wir die neueste Version finden, die Java 8 unterstützt.

Und hier ist sie, 2.7.18. Laut ihrem Blog ist 2.7.18 die neueste Version, die Spring Boot 2.x und dementsprechend Java 8 und Java 11 unterstützt:

Nach 5,5 Jahren und 121 Releases markiert 2.7.18 das Ende des Open-Source-Supports für Spring Boot 2.x. Bitte aktualisieren Sie so bald wie möglich auf Spring Boot 3. Wenn Sie noch nicht zum Aktualisieren bereit sind, steht Ihnen kommerzieller Support für Spring Boot 2.7.x zur Verfügung .

Beginnen Sie, sie zusammen zu verwenden

Voraussetzungen:

• Java 8
• GlassFish 4.1.2
• Spring Boot 2.7.18
• Maven

Die Spring Boot Community bietet Empfehlungen zum Ausführen der Spring Boot-Anwendung in der EE-Umgebung + offizielle Dokumentation

pom.xml

Die minimale und ausreichende pom.xml zum Erstellen und Ausführen der Anwendung sieht wie folgt aus:

 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <groupId>io.github.isharipov</groupId> <artifactId>sb2-to-gf4</artifactId> <version>1.0-SNAPSHOT</version> <packaging>war</packaging> <properties> <maven.compiler.source>8</maven.compiler.source> <maven.compiler.target>8</maven.compiler.target> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <exclusions> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> </exclusion> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-websocket</artifactId> </exclusion> </exclusions> <scope>provided</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>

Dabei musst Du auf zwei Dinge achten:

1. Ich verpacke die Anwendung als War-Datei, um dem Anwendungsserver klar zu machen, dass ich eine Webanwendung bereitstelle

   
   

    <packaging>war</packaging>

2. Ich schließe eingebetteten Tomcat aus, füge die Abhängigkeit spring-boot-starter-tomcat hinzu, schließe zwei interne Abhängigkeiten aus und füge den bereitgestellten Umfang hinzu

   
   

    <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <exclusions> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> </exclusion> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-websocket</artifactId> </exclusion> </exclusions> <scope>provided</scope> </dependency>

Mit diesem Ansatz können Sie Tomcat einbinden und nur für die Spring Boot-Laufzeit verfügbar machen, sodass Sie die Anwendung unabhängig vom Anwendungsserver ausführen können. Diese Trennung ist wichtig. Spring platziert diese Abhängigkeit in einem separaten Ordner namens lib-provided innerhalb des resultierenden Artefakts. Sie haben jetzt mindestens drei Optionen zum Ausführen des resultierenden Artefakts:

• Bereitstellen auf GlassFish – grundsätzlich gibt es drei Möglichkeiten, eine Anwendung bereitzustellen :
  • GlassFish-Administrator-Benutzeroberfläche
  • Kopieren Sie Ihre Archivdatei in das Autodeploy-Verzeichnis unter domain-dir/autodeploy
  • asadmin API - Bereitstellungsbefehl
• Ausführen mit java -jar : spring-boot-maven-plugin erstellt zwei Artefakte - war und war.original . Das einfache war enthält lib-provided , das original nicht.
• Starten Sie die Anwendung in Ihrer bevorzugten IDE - für die IntelliJ IDEA Community Edition müssen Sie unter Run/Debug Configuration die folgende Option hinzufügen

Durch den Ausschluss der folgenden Abhängigkeiten können wir die resultierende Artefaktgröße reduzieren:

 <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> </exclusion> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-websocket</artifactId> </exclusion>

Anwendungsklasse

Um eine Spring Boot-Anwendung auf einem Anwendungsserver auszuführen, müssen Sie zwei Änderungen an der Hauptanwendungsklasse vornehmen.

Normalerweise würden Sie zum Einrichten einer einfachen Webanwendung eine öffentliche Klasse mit einer main erstellen und sie mit der Annotation „@SpringBootApplication“ versehen.

 @SpringBootApplication public class Application { private static final Logger LOGGER = LoggerFactory.getLogger(Application.class); public static void main(String[] args) { SpringApplication.run(Application.class, args); } }

Daher, wie oben erwähnt, zwei Änderungsanträge:

1. Anwendungsklasse vom SpringBootServletInitializer erben
2. Überschreiben Sie die geschützte SpringApplicationBuilder-Methode configure(SpringApplicationBuilder builder)

 @SpringBootApplication public class Application extends SpringBootServletInitializer { private static final Logger LOGGER = LoggerFactory.getLogger(Application.class); public static void main(String[] args) { LOGGER.debug("From main"); SpringApplication.run(Application.class, args); } @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder application) { LOGGER.debug("From configure"); return application.sources(Application.class); } }

Bereitstellungsdeskriptor

Und zu guter Letzt müssen Sie Deployment Descriptor hinzufügen

Sie müssen also im Ordner main → src → webapp → WEB-INF die folgende Datei ablegen – glassfish-web.xml :

 <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd"> <glassfish-web-app> <class-loader delegate="false"/> <session-config> <session-manager/> </session-config> <jsp-config/> </glassfish-web-app>

Lesen Sie mehr über Deployment Descriptor

Lesen Sie mehr über Class Loader Delegation

Einpacken

1. Scheuen Sie sich nicht, ältere Technologien zu nutzen
2. Bleiben Sie neugierig und entwickeln Sie Ihre Fähigkeiten weiter
3. Viel Glück

GitHub

LinkedIn