Tomcat-Webanwendungen schützen

tomcat verwandelt ein WAR in eine eigenständige Tomcat-Basis. Dabei kommen die im Packager enthaltenen Tomcat-Komponenten zum Einsatz; Ihre lokale Tomcat-Installation wird nicht angerührt.

1. Vorgehen in der GUI

  1. Wählen Sie auf der Seite „Anwendungstyp“ die Option Tomcat WAR.

    Tomcat WAR wählen

  2. Wählen Sie das Eingabe-WAR, die mitgelieferte Java-Version und die Zielplattformen und entscheiden Sie sich für den einfachen oder den erweiterten Modus.

    Eingabe, Java-Version, Zielplattform und Modus wählen

  3. Wählen Sie im erweiterten Modus Tomcat 9 oder 10.1 oder belassen Sie die automatische Erkennung und setzen Sie bei Bedarf Kontextpfad, JVM-Startoptionen und Ausschlussregeln. Der einfache Modus bestimmt die Tomcat-Version aus dem Kompatibilitätsscan. Was die einzelnen Optionen bewirken, steht unter Protector4J Erweiterte Moduseinstellungen.

    Tomcat-Version, Kontextpfad und Ausschlussregeln konfigurieren

  4. Wählen Sie das Ausgabeverzeichnis, prüfen Sie die Zusammenfassung und klicken Sie auf Schutz ausführen.

    Ausgabeverzeichnis wählen und Schutz ausführen

2. CLI-Beispiele

Kontextpfad setzen:

p4j tomcat app.war dist --context /app

Kompatibilitätsscan und automatisches Anwenden der Empfehlungen:

p4j tomcat app.war --compat-scan
p4j tomcat app.war dist --compat-apply --context /app

Die beiden Optionen lassen sich nicht gemeinsam verwenden. Sie unterscheiden sich so:

OptionWirkungWann sinnvoll
--compat-scanUntersucht das Eingabe-WAR, gibt Risiken und Konfigurationsempfehlungen aus und endet. Es wird nichts encodiert und kein dist erzeugt, daher ist kein Ausgabeverzeichnis nötig.Lesen Sie den Bericht zuerst beim erstmaligen Schutz, nach einem Update Tomcat-naher Abhängigkeiten, nach Änderungen an Schutzumfang oder JSP-Einstellungen und bei der Suche nach Kompatibilitätsproblemen.
--compat-applyScannt, übernimmt die konservativen Empfehlungen und encodiert anschließend die Ausgabe. Daher ist ein Ausgabeverzeichnis erforderlich.Zum Abschließen der Paketierung, wenn Sie das Scanergebnis gelesen und die Empfehlungen akzeptiert haben. Eignet sich auch für wiederholte Builds und CI-Pipelines mit bereits geprüften Regeln.

Bei tomcat kann --compat-apply anhand des Scanergebnisses Ausschlussregeln ergänzen sowie Tomcat-Version, ZIP-Overlay und Archivsuffix anpassen. Für diese drei hat ein auf der Kommandozeile ausdrücklich gesetzter Wert Vorrang. Empfohlene Ausschlüsse werden standardmäßig mit Ihren eigenen --exclude-Mustern zusammengeführt; geben Sie zusätzlich --no-compat-excludes an, wenn Sie das nicht möchten. Der Scanner führt nur eine statische heuristische Analyse durch. Probleme, die eine Quelltextänderung erfordern, behebt --compat-apply nicht, und die paketierte Anwendung braucht weiterhin Regressionstests auf der Zielplattform.

Die übrigen CLI-Befehle, alle Optionen, Umgebungsvariablen und Automatisierungsbeispiele finden Sie in der CLI-Referenz.

--tomcat-version steht standardmäßig auf auto. Setzen Sie es auf 9 oder 10.1, wenn Sie es ausdrücklich festlegen wollen:

p4j tomcat app.war dist --context /app --tomcat-version 10.1

3. Aufbau der Ausgabe

dist/
├── bin/
│   ├── catalina.sh
│   ├── startup.sh
│   ├── shutdown.sh
│   └── *.bat
├── conf/p4jx/
│   ├── contexts.list
│   ├── protected-classes.list
│   └── allowed-prefixes.list
├── protected/
│   └── app.p4jx
├── lib/
│   ├── p4jx-tomcat-runtime.jar
│   └── tomcat-runtime-deps.jar
├── vlxjre/
├── run.sh
└── run.bat

Standardmäßig entsteht kein physisches WAR. web.xml, statische Ressourcen, ungeschützte Klassen, Metadaten-Stubs und geschützte Implementierungen liegen alle in protected/<context>.p4jx und werden Tomcat über das P4JX-WebResourceSet bereitgestellt.

4. Starten und Stoppen

Im Vordergrund ausführen:

./run.sh

Im Hintergrund starten und stoppen, wie bei Tomcat üblich:

./bin/startup.sh
./bin/shutdown.sh

Unter Windows verwenden Sie die entsprechenden .bat-Dateien. Protokolle landen im Verzeichnis logs/ der Ausgabe.

Für Windows-Ziele lässt sich zusätzlich ein nativer Starter erzeugen, der den eingebetteten Tomcat im Vordergrund startet — siehe Windows-EXE-Starter erzeugen.

JVM-Startoptionen

Tragen Sie beim Paketieren in der GUI unter JVM-Startoptionen eine Option pro Zeile ein oder setzen Sie sie auf der Kommandozeile:

p4j tomcat app.war dist \
  --context /app \
  --jvm-option -Xms1g \
  --jvm-option -Xmx2g

Änderung in einem bereits ausgelieferten Paket:

  • macOS und Linux: Bearbeiten Sie bin/catalina.sh und ergänzen Sie in run_java() nach der Zeile JVM_OPTS=(...) die Zeile JVM_OPTS+=("-Xms1g" "-Xmx2g"). Das gilt sowohl für den Vordergrundbetrieb als auch für den Start über startup.sh.
  • Windows, Vordergrund: Bearbeiten Sie bin\catalina.bat und ergänzen Sie nach der vorhandenen Zeile set "JVM_OPTS=..." die Zeile set "JVM_OPTS=%JVM_OPTS% -Xms1g -Xmx2g".
  • Windows, Hintergrund: Fügen Sie in bin\startup.bat vor dem Aufruf von catalina.bat die Zeile set "APP_JAVA_OPTS=-Xms1g -Xmx2g" ein. Brauchen Sie einen dauerhaften Satz Optionen für Vorder- und Hintergrund, ist es einfacher, das Paket über GUI oder CLI neu zu erzeugen.

Sie können APP_JAVA_OPTS auch dem Befehl voranstellen, damit es nur für diesen Lauf gilt. Vollständige Beispiele für CMD, PowerShell und Skripte finden Sie unter JVM-Startoptionen.

5. Die Tomcat-Version wählen

API-Namensraum im WARTomcatBenötigtes Java
javax.servlet.*Tomcat 9Java 8, 11, 17, 21 oder 25
jakarta.servlet.*Tomcat 10.1Java 11, 17, 21 oder 25

Die automatische Erkennung bestimmt den API-Namensraum zuerst aus den Anwendungsklassen und Deployment-Deskriptoren; JAR-Namen dienen nur als ergänzender Hinweis. Sind javax und jakarta beide im Einsatz, verzichtet das Werkzeug auf eine Vermutung.

6. JSP

Enthält ein WAR JSP-Dateien, werden diese beim Encoding standardmäßig zu Servlet-Klassen und URL-Zuordnungen vorkompiliert. Würden JSPs zur Laufzeit übersetzt, entstünden neue Klassen aus dem Tomcat-Arbeitsverzeichnis — außerhalb der Grenzen, die die geschützte Runtime für Klassendefinitionen zulässt.

Sie können das ausdrücklich steuern:

--precompile-jsp
--no-precompile-jsp

Behalten Sie in der Produktion die standardmäßige Vorkompilierung bei. Ohne sie können in einer JSP-basierten Anwendung Seiten nicht mehr laden.

7. Schutzumfang und Ausschlussregeln

Standardmäßig werden die Anwendungsklassen unter WEB-INF/classes geschützt, WEB-INF/lib dagegen nicht. Web-nahe Klassen lassen sich ausschließen:

p4j tomcat app.war dist \
  --context /app \
  --exclude 'com.example.web.**,com.example.dto.**'

Schließen Sie zuerst Servlets, Filter und Listener aus, ebenso DTOs, Konfigurationsklassen, Entitäten, JNI-Brückenklassen und alles, was der Container erweitern muss. Der Kompatibilitätsscan gibt dazu konservative Empfehlungen.

8. Eine weitere Anwendung im selben Tomcat-Paket ergänzen

p4j tomcat second.war dist \
  --append-app \
  --context /second

Randbedingungen:

  • Der Kontextpfad darf nicht mit einer vorhandenen Anwendung kollidieren.
  • Vorhandene und neue Anwendung müssen dieselbe Tomcat-Hauptversion, Java-Version und Zielplattform verwenden.
  • Ohne --append-app verweigert das Werkzeug das Schreiben in ein vorhandenes Tomcat-Paket.
  • Aktivieren Sie in der GUI Anwendung an vorhandenen Tomcat-Ordner anhängen und wählen Sie das vorhandene Verzeichnis.

9. Hinweis zu Java 8

Bei Java-8-Zielen wird das ZIP-Overlay automatisch aktiviert, damit das Tomcat-WebResourceSet das geschützte Archiv öffnen kann.