Installation und Einrichtung von
Tomcat
Für das SuperX-Kernmodul 6.0 empfehlen wir Tomcat 10.1 mit Java 21. Die folgenden Beispiele beziehen sich überwiegend auf Ubuntu Linux 26.04. Bei anderen Linux-Distributionen sind die Konfigurationsschritte weitgehend identisch, die Paketnamen und Pfade können aber abweichen.
Der Umstieg von Tomcat 9 auf Tomcat 10 ist kein reines Versionsupdate. Die Java-EE-Schnittstellen wurden von javax.* nach jakarta.* umgestellt. Für Tomcat 10 wird eine dafür geeignete SuperX-Webanwendung benötigt. Weitere Hinweise dazu stehen im Abschnitt Wechsel von Tomcat 9 auf Tomcat 10.
|
Tomcat aus Linux Distributionen
Da die Versionsnummern des Tomcat nicht immer zu SuperX passen, können Sie einen eigenen Tomcat bzw. den im SuperX-Kernmodul mitgelieferten Tomcat nutzen. Auch wenn Sie mehrere Tomcats auf einem Server betreiben, kann es sinnvoll sein, Tomcat manuell zu installieren. Der Betrieb von Tomcat aus der jeweiligen Linux-Distribution hat jedoch den Vorteil, dass man
- benötigte Drittsoftware direkt mitinstallieren kann
- die Apache-Integration einfacher einrichten kann
- regelmäßige Sicherheitsupdates und Bugfixes über die Paketverwaltung beziehen kann
- Tomcat in der Regel bereits als systemd-Dienst erhält
Wenn eine für SuperX geeignete Tomcat-Version in der Distribution enthalten ist, empfehlen wir daher die Installation aus der Distribution.
Tomcat aus der Ubuntu-Distribution
Im Folgenden wird das Vorgehen für Ubuntu Linux 26.04 mit Java 21 und Tomcat 10.1 beschrieben. Zunächst wechseln Sie in die root-Shell mit
sudo -i
Java 21, Tomcat 10 und den Apache-Webserver installieren:
apt-get update apt-get install -y openjdk-21-jdk tomcat10 apache2
Tomcat anschließend zunächst stoppen:
systemctl stop tomcat10.service
Die installierten Versionen können Sie prüfen mit
java -version /usr/share/tomcat10/bin/version.sh
Die Konfiguration des Distributions-Tomcat liegt üblicherweise in
/etc/tomcat10/server.xml
und die Webanwendungen in
/var/lib/tomcat10/webapps
Kopieren Sie die zu Tomcat 10 passende SuperX-Webanwendung in das webapps-Verzeichnis. Der Tomcat-Dienstbenutzer muss auf die benötigten Dateien zugreifen können; die Eigentümer- und Schreibrechte sollten auf die tatsächlich erforderlichen Verzeichnisse begrenzt werden.
Beim HTTP-Connector in der server.xml setzen Sie die Zeichenkodierung auf UTF-8. Wenn Apache und Tomcat auf demselben Server laufen, empfehlen wir außerdem die Bindung an localhost:
<Connector port="8080" protocol="HTTP/1.1"
address="127.0.0.1"
connectionTimeout="20000"
URIEncoding="UTF-8" />
Die weiteren Einstellungen für den Betrieb hinter Apache werden unter Apache Anbindung erläutert. Weitere Details zur server.xml siehe SuperX-Installationshandbuch.
Unter Ubuntu können Java-Optionen üblicherweise in der Datei
/etc/default/tomcat10
hinterlegt werden, z.B.:
JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64 JAVA_OPTS="-Djava.awt.headless=true -DSuperX-DB-PROPERTIES-SET=true -Xmx3700M"
Der Speicherwert ist nur ein Beispiel. Prüfen Sie mit systemctl cat tomcat10, welche Konfigurationsdateien der installierte Dienst tatsächlich einliest. Die vom Paket bereitgestellte systemd-Service-Datei sollte nicht direkt bearbeitet werden; bei Bedarf verwenden Sie eine systemd-Override-Datei.
Starten Sie Tomcat mit
systemctl start tomcat10.service
und prüfen Sie den Status mit
systemctl status tomcat10.service
Wenn der HTTP-Connector nur an 127.0.0.1 gebunden ist, kann der Zugriff auf demselben Server getestet werden mit
curl -I http://127.0.0.1:8080/superx/
Für den Aufruf vom Arbeitsplatzrechner wird anschließend die Apache-Anbindung eingerichtet.
Tomcat unter anderen Linux-Distributionen
Auch unter SUSE Linux und Red Hat Enterprise Linux können Sie den Tomcat aus der Distribution oder manuell installieren. Die genauen Paketnamen, Dienstnamen und Verzeichnisse sind distributionsabhängig. Entscheidend sind eine geeignete Tomcat-10.1-Version, Java 21, eine kompatible SuperX-Webanwendung und die Konfiguration des HTTP-Connectors bzw. AJP-Connectors.
Ältere Verfahren mit rctomcat, chkconfig oder SuSEconfig werden hier nicht mehr beschrieben. Für die Dienstverwaltung wird systemd verwendet.
Tomcat aus der Distribution mit abweichender Userkennung oder anderem webapps-Verzeichnis
Wenn Sie Tomcat aus der Distribution nutzen, läuft der Dienst unter einer dafür eingerichteten Systemkennung. Bei Ubuntu liegt das webapps-Verzeichnis üblicherweise unter /var/lib/tomcat10/webapps.
| Standardmäßig hat der Tomcat-Dienstbenutzer keine Login-Shell. Dies sollte aus Sicherheitsgründen so bleiben. |
Sie können das Verzeichnis der Webanwendungen auch ändern, indem Sie in der Datei /etc/tomcat10/server.xml beim Element Host das Attribut appBase anpassen, z.B.:
<Host name="localhost" appBase="/home/superx/webserver/tomcat/webapps"
unpackWARs="true" autoDeploy="false">
Beachten Sie, dass der Tomcat-Dienstbenutzer Lese- und Ausführungsrechte auf den gesamten benötigten Verzeichnispfad benötigt. Schreibrechte sollten nur für tatsächlich beschreibbare Verzeichnisse vergeben werden, etwa für temporäre Dateien oder SuperX-Logdateien. Auf gemeinsam verwendeten Verzeichnissen kann die Gruppenberechtigung entsprechend angepasst werden.
Wenn Sie als User superx neue Dateien anlegen und eine gemeinsam verwendete Gruppe eingerichtet haben, kann eine passende umask helfen:
# Full access to user and group, none for others: umask u=rwx,g=rwx,o=
Die konkrete Gruppenkennung und die Eigentümerschaft richten sich nach der Installation. Beachten Sie auch die Hinweise für Tomcat und Kettle.
Tomcat und Kettle
Im Homeverzeichnis des Benutzers, unter dem Tomcat läuft, sollte das Verzeichnis .kettle mit der Datei kettle.properties angelegt werden. Die Datei kann zunächst leer sein. Ermitteln Sie zuerst das Homeverzeichnis des Tomcat-Benutzers, z.B. mit
getent passwd tomcat
Liegt dieses bei Ubuntu unter /var/lib/tomcat10, können Sie als root Folgendes ausführen:
install -d -o tomcat -g tomcat /var/lib/tomcat10/.kettle touch /var/lib/tomcat10/.kettle/kettle.properties chown tomcat:tomcat /var/lib/tomcat10/.kettle/kettle.properties
| Bei einer Distributionsaktualisierung sollte geprüft werden, ob das Homeverzeichnis des Tomcat-Benutzers weiterhin korrekt gesetzt ist. |
Tomcat manuell installieren
Sie können auch spezielle Versionen von Tomcat herunterladen und installieren. Oder Sie verwenden den im SuperX-Kernmodul mitgelieferten Tomcat. Speicherort ist z.B. /home/superx/webserver/tomcat.
Bei einer Neuinstallation bzw. einem Versionswechsel sollten Sie die Konfiguration der neuen Tomcat-Version als Ausgangspunkt verwenden. Kopieren Sie nicht einfach die kompletten alten Verzeichnisse bin, lib und conf darüber. Auch bisher benötigte Zusatzbibliotheken und Java-Optionen müssen auf Kompatibilität geprüft werden.
Tomcat als Dienst
Damit Tomcat beim Systemstart automatisch hochfährt und beim Herunterfahren kontrolliert gestoppt wird, kann man einen systemd-Dienst anlegen. Im Beispiel liegt SuperX unter /home/superx und Tomcat wird vom Benutzer superx gestartet. Für eine Installation aus der Linux-Distribution ist der Dienst in der Regel bereits vorhanden.
Service-Scripte
Zunächst legen wir als User superx im Verzeichnis tomcat/bin zwei Dateien an.
startup_service.x:
#!/bin/bash # Startup script for Apache Tomcat with systemd set -e # Load the service settings . /home/superx/db/bin/SQL_ENV export CATALINA_BASE=/home/superx/webserver/tomcat export CATALINA_HOME=/home/superx/webserver/tomcat export CATALINA_TMPDIR=/home/superx/webserver/tomcat/temp # Start Tomcat cd "$CATALINA_BASE" && exec "$CATALINA_HOME/bin/catalina.sh" run
und shutdown_service.x:
#!/bin/bash # Shutdown script for Apache Tomcat with systemd set -e # Load the service settings . /home/superx/db/bin/SQL_ENV export CATALINA_BASE=/home/superx/webserver/tomcat export CATALINA_HOME=/home/superx/webserver/tomcat export CATALINA_TMPDIR=/home/superx/webserver/tomcat/temp # Stop Tomcat cd "$CATALINA_BASE" && exec "$CATALINA_HOME/bin/catalina.sh" stop
In der Datei SQL_ENV sollten die für Tomcat benötigten Umgebungsvariablen, insbesondere JAVA_HOME für Java 21 und die Java-Optionen, korrekt gesetzt bzw. exportiert werden. Der Pfad zu Java ist von der Distribution abhängig.
Dienst einrichten
Legen Sie als User root die Datei /etc/systemd/system/tomcat_superx.service an, mit dem Inhalt:
[Unit] Description=Tomcat SuperX After=network.target
[Service] Type=simple User=superx Group=users WorkingDirectory=/home/superx/webserver/tomcat/bin ExecStart=/bin/bash /home/superx/webserver/tomcat/bin/startup_service.x ExecStop=/bin/bash /home/superx/webserver/tomcat/bin/shutdown_service.x
[Install] WantedBy=multi-user.target
Die Gruppe users ist hier nur ein Beispiel und muss gegebenenfalls angepasst werden. Der Eintrag EnvironmentFile=/home/superx/db/bin/SQL_ENV wird nicht benötigt, da die Skripte die SQL_ENV bereits als Bash-Skript einlesen. systemd kann unter EnvironmentFile keine beliebigen Bash-Befehle ausführen.
Den Dienst aktivieren und starten Sie mit
systemctl daemon-reload systemctl enable tomcat_superx systemctl start tomcat_superx
Den Status und die Logmeldungen können Sie prüfen mit
systemctl status tomcat_superx journalctl -u tomcat_superx -e
Wenn Sie die Service-Datei ändern, müssen Sie danach systemctl daemon-reload ausführen. Den Dienst deaktivieren Sie mit
systemctl disable tomcat_superx
Für mögliche SELinux-Probleme bei Shell-Skripten in systemd-Diensten siehe SELinux im SuperX-Installationshandbuch.
Tomcat Logging
Tomcat Logging mit systemd
Je nach Installationsart erscheinen Tomcat-Meldungen im systemd-Journal oder in Dateien unter $CATALINA_BASE/logs. Bei einem manuell installierten Tomcat kann z.B. die Datei catalina.out vorhanden sein. Bei der Ubuntu-Distributionsinstallation sollte auch das systemd-Journal geprüft werden.
Alle Journalmeldungen anzeigen:
journalctl
Die Meldungen eines bestimmten Tomcat-Dienstes anzeigen, z.B.:
journalctl -u tomcat10 -e journalctl -u tomcat_superx -e
Die Meldungen live verfolgen:
journalctl -u tomcat10 -f
Apache Anbindung
In Systemumgebungen, in denen bereits ein Webserver wie Apache läuft, bietet es sich an, den SuperX-Tomcat mit dem Webserver zu verbinden. Der Webserver kann so konfiguriert werden, dass Aufrufe zu https://superx.example.de/superx/ an Tomcat weitergeleitet werden. Dadurch müssen die internen Tomcat-Ports nicht nach außen freigegeben werden. Die HTTPS-Verschlüsselung und die Zertifikatsverwaltung können vom Apache übernommen werden. Wir empfehlen daher generell die Anbindung von Tomcat an Apache für einen Produktivbetrieb.
Für die Verbindung zwischen Apache und Tomcat gibt es verschiedene Möglichkeiten:
- HTTP über Port 8080 mit ProxyPass (empfohlen)
- AJP über Port 8009 mit ProxyPass (Alternative)
- Mod-JK für bestehende Installationen
Wenn Apache und Tomcat auf demselben Server laufen, sollten die internen Connectoren nur an 127.0.0.1 gebunden werden. Bei getrennten Servern muss die Verbindung über ein vertrauenswürdiges und entsprechend geschütztes Netzwerk erfolgen.
ProxyPass über HTTP (Port 8080)
Wir empfehlen die HTTP-Anbindung über mod_proxy und mod_proxy_http. Sie ist einfach zu konfigurieren, verwendet das übliche HTTP-Protokoll und benötigt keinen AJP-Connector. AJP bietet zusätzliche Zugriffsmöglichkeiten auf Tomcat-interne Informationen und benötigt deshalb besondere Absicherung. HTTP über localhost ist damit bei gleicher Zugangsbeschränkung die einfacher zu betreibende Variante. Der interne HTTP-Verkehr ist dabei nicht verschlüsselt; dieses Beispiel gilt deshalb für Apache und Tomcat auf demselben Server.
Unter Ubuntu aktivieren Sie die benötigten Apache-Module mit
a2enmod proxy proxy_http ssl
Tomcat konfigurieren
In der server.xml (bei Ubuntu /etc/tomcat10/server.xml) richten Sie den HTTP-Connector ein:
<Connector port="8080" protocol="HTTP/1.1"
address="127.0.0.1"
connectionTimeout="20000"
URIEncoding="UTF-8"
proxyName="superx.example.de"
proxyPort="443"
scheme="https"
secure="true" />
Der Wert proxyName muss dem öffentlich verwendeten Hostnamen entsprechen. Die Angaben proxyPort="443", scheme="https" und secure="true" teilen Tomcat mit, dass die Anwender die Webanwendung über HTTPS am Apache aufrufen. Diese Konfiguration ist für eine ausschließlich über HTTPS erreichbare SuperX-Anwendung mit einem festen öffentlichen Hostnamen gedacht.
Apache konfigurieren
Im Apache-VirtualHost für HTTPS (unter Ubuntu z.B. in /etc/apache2/sites-available/superx.conf) ergänzen Sie die Weiterleitung:
<VirtualHost *:443>
ServerName superx.example.de
SSLEngine on
SSLCertificateFile /etc/ssl/certs/superx.crt
SSLCertificateKeyFile /etc/ssl/private/superx.key
ProxyRequests Off
ProxyPass "/superx" "http://127.0.0.1:8080/superx"
ProxyPassReverse "/superx" "http://127.0.0.1:8080/superx"
</VirtualHost>
Die Zertifikatspfade sind Beispiele. Bestehende VirtualHosts werden entsprechend ergänzt; die SSL-Konfiguration muss nicht doppelt angelegt werden. ProxyPass leitet die Anfragen an Tomcat weiter, ProxyPassReverse passt bestimmte vom Backend gelieferte HTTP-Weiterleitungen an. URLs, die eine Webanwendung direkt in HTML erzeugt, werden dadurch nicht automatisch korrigiert.
Nach den Änderungen prüfen Sie die Konfiguration und starten die Dienste neu:
apache2ctl configtest systemctl restart tomcat10 systemctl reload apache2
Der Dienstname muss gegebenenfalls an die eigene Installation angepasst werden.
Falsche localhost-Adressen in DBForms bzw. HTML-Ausgaben
Wenn die öffentliche SuperX-Adresse über HTTPS aufgerufen wird, Tomcat intern aber nur den HTTP-Aufruf über localhost:8080 erkennt, können Webanwendungen fehlerhafte absolute URLs erzeugen. Das kann z.B. bei DBForms zu einem solchen HTML-Eintrag führen:
<base href="http://localhost:8080/superx/" />
Der Browser des Anwenders versucht dann, Ressourcen von seinem eigenen Rechner (localhost) zu laden. Bilder, Skripte oder Verweise funktionieren deshalb gegebenenfalls nicht. Mit den oben beschriebenen Connector-Attributen proxyName, proxyPort, scheme und secure kann Tomcat den korrekten öffentlichen Servernamen und das HTTPS-Schema an die Webanwendung melden.
| {{{1}}} |
Wenn mehrere öffentliche Hostnamen oder unterschiedliche Zugriffsschemata benötigt werden, reicht ein fest eingetragener proxyName gegebenenfalls nicht aus. Dann kann eine Konfiguration mit vertrauenswürdigen Proxy-Headern und der Tomcat-RemoteIpValve sinnvoll sein. Der Proxy muss solche Header kontrolliert setzen; unkontrolliert vom Client übernommene Header sind aus Sicherheitsgründen ungeeignet.
ProxyPass über AJP (Port 8009)
Alternativ kann die Verbindung über das AJP-Protokoll erfolgen. Dafür benötigen Sie beim Apache das Modul mod_proxy_ajp und auf Tomcat-Seite einen AJP-Connector. AJP ist weiterhin unterstützt, sollte aber nur in einem vertrauenswürdigen Netzwerk oder lokal verwendet werden. Das Secret schützt vor unberechtigten AJP-Verbindungen, verschlüsselt die Übertragung jedoch nicht.
Unter Ubuntu aktivieren Sie das Modul mit
a2enmod proxy proxy_ajp
In der Tomcat-server.xml:
<Connector protocol="AJP/1.3"
address="127.0.0.1"
port="8009"
secretRequired="true"
secret="HIER_EIN_LANGES_ZUFAELLIGES_SECRET_EINTRAGEN"
URIEncoding="UTF-8" />
Im Apache-VirtualHost wird anstelle der HTTP-Weiterleitung die AJP-Weiterleitung verwendet:
ProxyPass "/superx" "ajp://127.0.0.1:8009/superx" secret=HIER_EIN_LANGES_ZUFAELLIGES_SECRET_EINTRAGEN
Beide Secrets müssen übereinstimmen und dürfen nicht als öffentliche Beispielwerte übernommen werden. Der Parameter secret bei ProxyPass ist ab Apache 2.4.42 verfügbar. Auf beiden Seiten sollte die Konfiguration vor unberechtigtem Zugriff geschützt werden. Eine parallele HTTP- und AJP-Weiterleitung für denselben Pfad ist nicht erforderlich.
Wenn Apache auf einem separaten Server läuft, muss statt 127.0.0.1 die geeignete interne IP-Adresse des Tomcat-Servers verwendet werden. Zusätzlich müssen Firewall und Netzabsicherung passend konfiguriert werden.
Weitere Details siehe Tomcat AJP Connector.
Mod-JK
Das Apache-Modul mod_jk wird weiterhin für bestehende AJP-Installationen unterstützt. Für neue SuperX-Installationen empfehlen wir jedoch die oben beschriebene Anbindung über ProxyPass. Unter Ubuntu können Sie Mod-JK bei Bedarf installieren und aktivieren mit
apt-get install -y libapache2-mod-jk a2enmod jk
Der AJP-Connector in Tomcat benötigt dieselben Sicherheitsvorgaben wie bei mod_proxy_ajp. In der workers.properties wird der Worker z.B. so eingerichtet:
worker.list=superx_tomcat worker.superx_tomcat.type=ajp13 worker.superx_tomcat.host=127.0.0.1 worker.superx_tomcat.port=8009 worker.superx_tomcat.secret=HIER_EIN_LANGES_ZUFAELLIGES_SECRET_EINTRAGEN
Die Weiterleitung kann in der Apache-Konfiguration so erfolgen:
JkMount /superx/* superx_tomcat JkMount /superx superx_tomcat
Apache und Tomcat Sicherheit
Für den Produktivbetrieb empfehlen wir folgende Grundeinstellungen:
- HTTPS wird nach außen am Apache bereitgestellt. Die internen Ports 8080 bzw. 8009 werden nicht über die öffentliche Firewall freigegeben.
- Bei Betrieb auf demselben Server werden die Tomcat-Connectoren an
127.0.0.1gebunden. - Nicht benötigte Connectoren werden in der
server.xmldeaktiviert. - Bei AJP wird ein eigenes, langes Secret verwendet; AJP sollte nicht über ungeschützte Netze betrieben werden.
- Der Tomcat-Dienst läuft ohne Root-Rechte. Konfigurationsdateien und die Webanwendung erhalten nur die benötigten Dateirechte.
- Apache, Tomcat und Java werden regelmäßig mit Sicherheitsupdates versorgt.
- Bei SELinux-bedingten Verbindungsproblemen oder Problemen mit systemd-Shell-Skripten siehe SELinux (Security-Enhanced Linux) im SuperX-Installationshandbuch.
Weitere Tipps zur Tomcat-Sicherheit siehe Tomcat Security How-To.
Einrichtung SSL
SSL Varianten
Sie können SSL/TLS direkt in Tomcat einrichten, normalerweise wird die Verschlüsselung aber im Webserver konfiguriert. Bei einer Apache-Tomcat-Anbindung empfehlen wir, HTTPS beim Apache zu beenden und den internen Tomcat-Connector nur lokal erreichbar zu machen.
SSL im Webserver
Unter Ubuntu benötigen Sie das Apache-Modul ssl. Es kann aktiviert werden mit
a2enmod ssl
Im HTTPS-VirtualHost wird das Zertifikat eingebunden, z.B.:
<VirtualHost *:443>
ServerName superx.example.de
SSLEngine on
SSLCertificateFile /etc/ssl/certs/superx.crt
SSLCertificateKeyFile /etc/ssl/private/superx.key
# Weitere Einstellungen, z.B. die ProxyPass-Anbindung, siehe oben.
</VirtualHost>
Zertifikat und Schlüssel müssen zum öffentlichen Hostnamen passen. Die Datei mit dem privaten Schlüssel darf nur von berechtigten Systembenutzern gelesen werden. Die tatsächlich verwendeten Pfade richten sich nach der Zertifikatsverwaltung vor Ort. Wenn zusätzlich Zugriffe auf Port 80 auf HTTPS umgeleitet werden sollen, kann ein eigener VirtualHost verwendet werden:
<VirtualHost *:80>
ServerName superx.example.de
Redirect permanent / https://superx.example.de/
</VirtualHost>
Die Apache-Konfiguration prüfen und neu laden:
apache2ctl configtest systemctl reload apache2
Zertifikate mit Let's Encrypt
Wenn der Server die Voraussetzungen für eine öffentliche ACME-Zertifikatsprüfung erfüllt, können Sie z.B. Let's Encrypt in Verbindung mit Certbot verwenden. Unter Ubuntu stehen dafür passende Pakete bereit:
apt-get install -y certbot python3-certbot-apache
Die konkrete Ausstellung, Einrichtung und automatische Verlängerung hängen davon ab, ob der Webserver öffentlich erreichbar ist und welche Zertifikatsverwaltung die Hochschule einsetzt. Weitere Informationen siehe Certbot und Let's Encrypt.
SSL im Tomcat
Falls kein vorgeschalteter Apache-Webserver vorhanden ist, kann Tomcat HTTPS auch direkt bereitstellen. In Tomcat 10.1 wird die TLS-Konfiguration über SSLHostConfig und Certificate vorgenommen. Beispiel mit vorhandenem PKCS12-Keystore:
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="/home/superx/tomcat-keystore.p12"
certificateKeystoreType="PKCS12"
certificateKeystorePassword="HIER_DAS_KEYSTORE_PASSWORT" />
</SSLHostConfig>
</Connector>
Der Keystore muss ein zum öffentlichen Hostnamen passendes Zertifikat und den privaten Schlüssel enthalten. Das Passwort im Beispiel muss durch einen eigenen sicheren Wert ersetzt und entsprechend geschützt werden. Bei direkt von außen erreichbarem Tomcat muss außerdem Port 8443 entsprechend abgesichert werden. Eine ausführliche Anleitung zum Erzeugen bzw. Einbinden von Zertifikaten steht in der offiziellen Tomcat-10.1-Dokumentation.
Wechsel von Tomcat 9 auf Tomcat 10
Mit Tomcat 10 wurden die Java-EE-Schnittstellen auf Jakarta EE umgestellt. Insbesondere wurden viele Paketnamen von javax.* nach jakarta.* geändert. Eine für Tomcat 9 bereitgestellte Webanwendung kann deshalb nicht ohne Weiteres mit Tomcat 10 verwendet werden. Für das SuperX-Kernmodul 6.0 empfehlen wir Tomcat 10.1 und Java 21.
Für den Versionswechsel muss insbesondere geprüft werden, ob die SuperX-Webanwendung und zusätzlich eingesetzte Bibliotheken für Tomcat 10 geeignet sind. Die Konfiguration der neuen Tomcat-Version sollte als Grundlage verwendet werden; die bisherigen Konfigurationsdateien sollten nicht vollständig übernommen werden. Auch bestehende Java-Optionen sowie die Apache-Anbindung müssen geprüft werden.
| Der Wechsel von Tomcat 9 auf Tomcat 10 wird wegen der umfangreicheren Umstellung in einem separaten Migrationsleitfaden behandelt. Bis dahin siehe offizielle Tomcat-Migrationshinweise. |