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
-
Wählen Sie auf der Seite „Anwendungstyp“ die Option Tomcat WAR.

-
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.

-
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.

-
Wählen Sie das Ausgabeverzeichnis, prüfen Sie die Zusammenfassung und klicken Sie auf 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:
| Option | Wirkung | Wann sinnvoll |
|---|---|---|
--compat-scan | Untersucht 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-apply | Scannt, ü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.shund ergänzen Sie inrun_java()nach der ZeileJVM_OPTS=(...)die ZeileJVM_OPTS+=("-Xms1g" "-Xmx2g"). Das gilt sowohl für den Vordergrundbetrieb als auch für den Start überstartup.sh. - Windows, Vordergrund: Bearbeiten Sie
bin\catalina.batund ergänzen Sie nach der vorhandenen Zeileset "JVM_OPTS=..."die Zeileset "JVM_OPTS=%JVM_OPTS% -Xms1g -Xmx2g". - Windows, Hintergrund: Fügen Sie in
bin\startup.batvor dem Aufruf voncatalina.batdie Zeileset "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 WAR | Tomcat | Benötigtes Java |
|---|---|---|
javax.servlet.* | Tomcat 9 | Java 8, 11, 17, 21 oder 25 |
jakarta.servlet.* | Tomcat 10.1 | Java 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-appverweigert 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.