Teil 6. Servlet-Container

Dieses Material ist Teil der Reihe „Einführung in die Unternehmensentwicklung“. Vorherige Artikel:

Im letzten Artikel haben wir uns mit Servlets vertraut gemacht und gelernt, wie man sie zum Erstellen von Webanwendungen verwendet. Es ist an der Zeit, einen wesentlichen Teil dieses Spaßes genauer unter die Lupe zu nehmen: Servlet-Behälter.

Inhaltsverzeichnis:

Was ist ein Servlet-Container?

Es handelt sich um ein Programm, das auf einem Server läuft und mit den von uns erstellten Servlets interagieren kann. Mit anderen Worten: Wenn wir unsere Webanwendung auf einem Server ausführen möchten, stellen wir zunächst einen Servlet-Container bereit und fügen dann Servlets darin ein. Der Arbeitsablauf ist einfach: Wenn der Client auf den Server zugreift, verarbeitet der Container seine Anfrage, bestimmt, welches Servlet sie verarbeiten soll, und leitet die Anfrage dann weiter. Teil 6. Servlet-Container – 2

Wie werden Servlet-Container verwendet?

Zusätzlich zum Weiterleiten von Anforderungen führt ein Servlet-Container weitere Funktionen aus:

Es generiert dynamisch HTML-Seiten aus JSP-Dateien.
Es verschlüsselt/entschlüsselt HTTPS-Nachrichten.
Es bietet eingeschränkten Zugriff für die Servlet-Verwaltung.

Im Großen und Ganzen hört sich das alles gut an. Jetzt müssen wir nur noch herausfinden, wie wir das alles in die Praxis umsetzen können. Nun ja, um zu lernen, wie man etwas benutzt, tauchen Sie einfach ein und versuchen Sie, es zu benutzen :) Also, heute werden wir üben! Der beliebteste Servlet-Container ist Apache Tomcat . Es ist Open Source und kann kostenlos genutzt werden. Laden Sie hier Tomcat für Ihr Betriebssystem herunter und wir erkunden die Arbeit mit Containern „in Aktion“.

Tomcat installieren und starten

Um Tomcat zu installieren, entpacken Sie einfach das heruntergeladene Archiv in das gewünschte Verzeichnis.
Bitte beachten Sie, dass Tomcat zum Starten und Ausführen Java Version 8 oder höher erfordert. Stellen Sie sicher, dass die Umgebungsvariable JAVA_HOME auf die aktuelle Version des JDK verweist.
Als Nächstes müssen Sie den Benutzerzugriff auf Tomcat konfigurieren . Dies erfolgt in der Datei tomcat-users.xml, die sich im Ordner conf befindet.

In Tomcat gibt es vier voreingestellte Rollen:
- manager-gui – Zugriff auf die grafische Benutzeroberfläche und die Statusseite
- manager-script – Zugriff auf die Textoberfläche und die Statusseite
- manager-jmx – Zugriff auf JMX und die Statusseite
- manager-status – Nur Zugriff auf die Statusseite
Im <tomcat-users>-Tag geben wir diese Rollen explizit an und weisen sie unserem Benutzer zu:
```
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<user username="user" password="password"
    roles="manager-gui, manager-script, manager-jmx, manager-status"/>
```
Jetzt ist alles startklar!
Führen Sie im Ordner „bin“ die Datei „startup.bat“ (startup.sh unter Linux) aus.
Öffnen Sie nach einigen Sekunden den Link http://localhost:8080/ in Ihrem Browser. Sie sehen ein grafisches Dashboard:

Wenn Sie ein Menü wie dieses sehen, läuft Tomcat.
Wenn es nicht ausgeführt wird, überprüfen Sie manuell die Umgebungsvariablen JAVA_HOME und CATALINA_HOME:
- JAVA_HOME – Dies muss auf die aktuelle Version von Java 8+ verweisen.
- CATALINA_BASE – Dies muss auf Tomcat verweisen oder fehlen (es sollte nicht auf eine andere Version von Tomcat verweisen).

Bereitstellen einer Anwendung in Tomcat

Es ist uns gelungen, Tomcat zu starten, daher ist es jetzt an der Zeit, ein Projekt darin bereitzustellen. Verwenden wir die Servlets aus dem vorherigen Artikel . MainServlet:


import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import java.io.IOException;
import java.io.PrintWriter;

@WebServlet("/hello")
public class MainServlet extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
       HttpSession session = req.getSession();
       Integer visitCounter = (Integer) session.getAttribute("visitCounter");
       if (visitCounter == null) {
           visitCounter = 1;
       } else {
           visitCounter++;
       }
       session.setAttribute("visitCounter", visitCounter);
       String username = req.getParameter("username");
       resp.setContentType("text/html");
       PrintWriter printWriter = resp.getWriter();
       if (username == null) {
           printWriter.write("Hello, Anonymous" + "
");
       } else {
           printWriter.write("Hello, " + username + "
");
       }
       printWriter.write("Page was visited " + visitCounter + " times.");
       printWriter.close();
   }
}

IndexServlet:


import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet("/")
public class IndexServlet extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
       resp.sendRedirect(req.getContextPath() + "/hello");
   }
}

Vor der Bereitstellung müssen wir unsere Servlets in eine WAR-Datei packen. Normalerweise wird hierfür Maven verwendet, aber um eine WAR-Datei zu erstellen, benötigen Sie eine web.xml-Datei, die eine Zuordnung für alle Servlets enthält. Wir haben die neue Annotation @WebServlet zum Schreiben der Servlets verwendet, sodass wir keine web.xml-Datei haben. Glücklicherweise kann IDEA die Drecksarbeit für uns erledigen, indem es unser Projekt in eine WAR-Datei verpackt. Öffnen Sie dazu die Projektstruktur (Strg+Umschalt+Alt+S) -> Artefakte -> Wählen Sie die gewünschte WAR-Datei aus -> Aktivieren Sie das Kontrollkästchen neben „In Projekterstellung einbeziehen“ -> Klicken Sie auf „OK“. Teil 6. Servlet-Container – 4

Lassen Sie uns das Projekt mit der Tastenkombination Strg+F9 erstellen. Jetzt befindet sich unsere WAR-Datei im Zielverzeichnis. Teil 6. Servlet-Container – 5

Die Datei kann in etwas Einfacheres umbenannt werden, z. B. servlet.war, und an einen günstigeren Ort verschoben werden, z. B. C:\\my\\.Wir legen es in einen Behälter . Es gibt zwei Möglichkeiten, dies zu tun.

Verwendung der grafischen Oberfläche

Folgen Sie dazu diesem Link: http://localhost:8080/manager/html . Tomcat sollte nach einem Benutzernamen und einem Passwort fragen.

Wenn Sie mir bis hierher gefolgt sind, lautet der Benutzername „user“ und das Passwort „password“ .

Nach erfolgreicher Anmeldung wird Ihnen der Tomcat Web Application Manager angezeigt. Der Abschnitt „Anwendungen“ enthält bereits 5 Anwendungen – das sind Tomcat-Dienstprogramme, die die Arbeit mit Tomcat einfacher machen. Sie können in Zukunft gelöscht werden.

Unten finden Sie den Abschnitt „Bereitstellen“. Hier können Sie das bereitzustellende WAR-Archiv auswählen. Geben wir den Pfad und den Kontext manuell ein:

Klicken Sie auf „Bereitstellen“ und wir sehen, dass unsere Anwendung im Abschnitt „Anwendungen“ angezeigt wird:
Über die grafische Oberfläche von Tomcat können wir eine Sitzung stoppen, neu starten und löschen sowie die Sitzungslänge festlegen. Bei der Bereitstellung haben wir den /demo-Kontext angegeben, was bedeutet, dass auf unsere Anwendung über http://localhost:8080/demo zugegriffen wird . Prüfen Sie. Alles sollte funktionieren.
Über das Dateisystem

Um die Anwendung auf diese Weise bereitzustellen, müssen Sie das Verzeichnis öffnen, in dem Tomcat entpackt wurde. Gehen Sie dann zum Ordner „webapps“. Hier finden Sie die Utilities, die uns bereits begegnet sind:

Wir müssen lediglich unsere Datei servlet.war hierher verschieben.

Wir warten ein paar Sekunden und sehen dann, dass ein neuer „Servlet“-Ordner aufgetaucht ist. Dies bedeutet, dass unsere Anwendung bereitgestellt wird. Gehen Sie zur Application Manager-Oberfläche unter http://localhost:8080/manager/ . Hier sehen wir, dass unsere Anwendung im /servlet-Kontext bereitgestellt wird:

Bei einer Bereitstellung auf diese Weise wird der Kontext automatisch basierend auf dem Namen der bereitgestellten WAR-Datei zugewiesen. Um den Kontext zu ändern, können Sie den neu erstellten Ordner, der die Anwendung enthält, umbenennen. Zuvor müssen Sie jedoch die WAR-Datei entfernen. Andernfalls stellt Tomcat die Anwendung mit dem Archivnamen erneut bereit.

Wie Sie sehen, ist die Bereitstellung von Anwendungen in Tomcat viel einfacher, als es den Anschein hat. Aber auch die anderen Funktionen sind einfach zu bedienen. Lass uns das Prüfen.

Verwendung von HTTPS anstelle von HTTP

Wenn Sie sich erinnern, haben wir uns in einem separaten Artikel mit dem Unterschied zwischen HTTP und HTTPS befasst . HTTPS ist das gleiche Protokoll wie HTTP, verschlüsselt jedoch die übertragenen Daten. Auf der Clientseite ist der Browser für die Verschlüsselung verantwortlich, auf der Serverseite müssen wir jedoch für die Verschlüsselung sorgen. Da Tomcat HTTP-Anfragen akzeptiert und weiterleitet, ist es sinnvoll, die Verschlüsselung an Tomcat zu delegieren. Dazu müssen wir:

Generieren Sie ein selbstsigniertes Zertifikat
Nehmen Sie weitere Servereinstellungen vor

Lasst uns das üben.

Generieren eines Zertifikats

Unabhängig von der Version enthält das JDK eine große Anzahl von Dienstprogrammen. Eines davon ist Keytool . Dies ist ein Tool zum Generieren und Arbeiten mit Verschlüsselungsschlüsseln. Um es zu verwenden, gehen Sie in der Befehlszeile zum Verzeichnis C:\\Programme\\Java\\jdk1.8.0_181\\bin und führen Sie den Befehl keytool -genkey -alias tomcat -keyalg RSA aus .

keytool – Der Name des Dienstprogramms, das wir mit Befehlszeilenoptionen ausführen
-genkey – Geben Sie an, dass wir einen neuen Schlüssel generieren möchten
-alias tomcat – Erstellt einen Schlüsselalias
-keyalg RSA – Wählen Sie RSA als Schlüsselgenerierungsalgorithmus aus

Nach Ausführung des Befehls startet das Dienstprogramm einen Dialog mit uns: Teil 6. Servlet-Container – 11

Geben Sie die erforderlichen Informationen ein. Jetzt haben wir einen Keystore in unserem Home-Verzeichnis (für Windows ist dies C:\\Users\\{Benutzername}\\.keystore) und einen Tomcat-Schlüssel darin erstellt. Wir haben ein einfaches Zertifikat erstellt, über das sich die meisten Browser beschweren werden. Für kommerzielle Anwendungen ist ein solches Zertifikat nicht geeignet, es kann nur zu Testzwecken verwendet werden. Auf einem Produktionsserver müssen Sie ein Zertifikat einer Zertifizierungsstelle verwenden (z. B. https://letsencrypt.org/ ).

Konfigurieren des Servers

Nachdem das Zertifikat nun fertig ist, müssen wir die Servereinstellungen anpassen, nämlich den SSL-Connector. Dies erfolgt in der Datei server.xml, die sich in apache-tomcat-9.0.30/conf/ befindet . Darin finden wir Blöcke wie diesen:


<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true">
        <SSLHostConfig>
            <Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
                         type="RSA" />
        </SSLHostConfig>
 </Connector>

und wir legen unsere Konfiguration daneben:


    <Connector
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           port="8443" maxThreads="200"
           scheme="https" secure="true" SSLEnabled="true"
           keystoreFile="C:\Users\user\.keystore" keystorePass="mypass"
           clientAuth="false" sslProtocol="TLS"/>

Wir weisen den Parametern „keystoreFile“ und „keystorePass“ die neuesten Werte zu, speichern die Datei und starten dann Tomcat mithilfe der Dateien „shutdown.bat“ und „startup.bat“ neu. Jetzt ist der Server bereit, HTTPS-Anfragen zu verarbeiten. Die Adresse hat sich nur geringfügig geändert: https://localhost:8443/demo/hello . Wenn Sie auf den Link klicken, erhalten Sie eine Warnung über die Vertrauenswürdigkeit des Zertifikats, was nicht überraschend ist. Wie bereits erwähnt, müssen Sie die Dienste einer der Zertifizierungsstellen in Anspruch nehmen, um ein normales Zertifikat zu erhalten. Aber vorerst haben wir unser Ziel erreicht: Die Anwendung läuft über das HTTPS-Protokoll, und das ist wichtig!

Dynamische Generierung von HTML-Seiten

Jetzt setzen wir unseren Überblick über Servlet-Container fort und betrachten eine weitere Funktion: die dynamische Generierung von HTML-Seiten. Stellen Sie sich eine perfekte Welt vor, in der Sie anstelle von langweiligem statischem HTML-Code Java-Code unter Verwendung von Variablen, Schleifen, Arrays und anderen Sprachkonstrukten schreiben könnten. Konnten Sie es sich vorstellen? Die gute Nachricht ist, dass es etwas Ähnliches gibt. Die schlechte Nachricht ist, dass diese Fantasie nicht ganz umgesetzt wird. Falls Sie es noch nicht erraten haben: Es handelt sich um JavaServer Pages (JSP). Kurz gesagt handelt es sich dabei um eine Technologie, mit der Sie Teile von Java-Code in eine HTML-Seite einfügen können. Zwar wird dieser Java-Code noch in HTML konvertiert, bevor er an den Client gesendet wird, dieser HTML-Code wird jedoch dynamisch unter Berücksichtigung verschiedener Faktoren generiert. Zum Beispiel, Sie können bedingte Anweisungen verwenden und je nach Bedingung unterschiedliche Inhalte zurückgeben. Beispiel einer JSP-Seite:


<%@ page language="java"" %>
<html>
<head>
<title>JSP</title>
</head>

<body>
<%
String firstName="name";
String secondName="surname";
    
    if (firstName.equals("name")){
      out.print("Hello: "+firstName+"<br>");
    }

    if (firstName.equals("name") && secondName.equals("surname"))
    {
      out.print("Hello, my dear friend! <br>");
    }
    else
    {
      out.print("I don't know you. Go away! <br>");
    }
%>
</body>
</html>

Mehr über JSP können Sie hier lesen. Letztlich geht es in diesem Artikel nicht um JSP – wir sind hier, um über Servlet-Container zu sprechen! Warum haben wir JSP erwähnt? Es ist ganz einfach: Ein Servlet-Container konvertiert Java-Code von JSP in HTML. Wenn ein Servlet JSP-Inhalte als Antwort zurückgeben soll, nimmt der Container dies zur Kenntnis und wandelt ihn zunächst in eine browserfreundliche HTML-Seite um, bevor er diesen Inhalt an den Client sendet. Heutzutage gibt es viele Analoga zur JSP-Technologie – Thymeleaf, FreeMarket, Moustache und andere. Sie funktionieren alle auf ähnliche Weise. Welche davon Sie für Ihre Arbeit wählen, ist Geschmackssache. Dies gilt auch für die Auswahl eines Servlet-Containers. In diesen Beispielen haben wir Tomcat verwendet, den am häufigsten verwendeten Container, aber einige Projekte verwenden auch andere Container. Es lohnt sich, einen kurzen Blick auf die beliebtesten zu werfen und zu überlegen, wie sie sich von Tomcat unterscheiden.

Alternativen zu Tomcat

GlassFish ist ein Open-Source-Container, dessen Entwicklung von Oracle unterstützt wird.

Im Gegensatz zu Tomcat handelt es sich um einen vollwertigen Webserver, der neben Servlets auch mit anderen Komponenten aus dem JavaEE-Framework zusammenarbeiten kann. Allerdings verbraucht es viel mehr RAM. Es besteht eine größere Flexibilität bei der Feinabstimmung des Servers, was seine Verwendung erschwert. Es sollte bei der Entwicklung von Anwendungen auf dem JavaEE-Framework verwendet werden.
WildFly war früher als JBoss bekannt . Es ist auch Open Source. Es wurde von Red Hat entwickelt. Der Name wurde geändert, um Verwechslungen mit einem anderen Produkt des Unternehmens – JBoss Enterprise Application Platform – zu vermeiden.

WildFly ist wie GlassFish ein vollwertiger Webserver. Unter der Haube nutzt WildFly übrigens Tomcat als Servlet-Container. Im Gegensatz zu GlassFish ist WildFly leichter und einfacher zu konfigurieren.
Jetty ist, wie die vorherigen, Open Source. Es wurde von Eclipse entwickelt.

Wie Tomcat handelt es sich um einen einfachen Servlet-Container ohne Unterstützung für alle Komponenten des JavaEE-Frameworks. Gleichzeitig ist es leichter und kann sogar auf einem Mobiltelefon ausgeführt werden. Es startet und stoppt schnell und lässt sich gut skalieren. Im Gegensatz zu Tomcat verfügt es über eine kleinere Community und Wissensbasis.
WebLogic ist eine lizenzierte Software, die vor der Nutzung erworben werden muss. Es gehört Oracle.

Es verfügt über einen etwas umfassenderen Funktionsumfang als Tomcat. Es kann mit dem FTP-Protokoll arbeiten. Beim Entwickeln und Testen von Anwendungen ist es jedoch nicht so flexibel.
WebSphere (genauer gesagt WebSphere Application Server) ist kostenpflichtige Software. Es wird von IBM entwickelt. Ähnlich wie WildFly und GlassFish handelt es sich um einen vollständigen Anwendungsserver. Aber es verfügt über eine benutzerfreundlichere Konfigurationsoberfläche und eine hohe Zuverlässigkeit im Betrieb.

Zu seinen Nachteilen gehört die Tatsache, dass es viele Ressourcen verbraucht und lange zum Starten und Stoppen benötigt, was bei der Entwicklung kleiner Projekte nicht sehr praktisch ist.

Die Wahl des richtigen Servlet-Containers oder Anwendungsservers hängt vom jeweiligen Projekt ab. Es gibt Projekte, bei denen sich selbst ein klarer Außenseiter als ausgezeichnete Wahl erweisen kann, aber zunächst ist es am besten, einen Servlet-Container eingehend zu untersuchen. Tomcat ist wahrscheinlich der perfekte Kandidat für diese Studie. Und wir haben bereits die ersten Schritte unternommen, um es zu studieren, aber jetzt liegt es an Ihnen! In den letzten Artikeln der Reihe „Einführung in die Unternehmensentwicklung“ lernen wir das MVC-Muster kennen. Teil 7. Einführung in das MVC-Muster (Model-View-Controller).