AEM enthält einen Standard-Fehler-Handler für die Verarbeitung von HTTP-Fehlern. Beispielsweise wird Folgendes gezeigt:
Um auf Fehler zu reagieren, stellt AEM unter /libs/sling/servlet/errorhandler
ein 404.jsp
-Skript bereit.
Da AEM auf Apache Sling basiert, sind weitere Informationen in der Apache-Dokumentation zur Fehlerbehandlung verfügbar.
In Autoreninstanzen ist CQ WCM Debug Filter standardmäßig aktiviert. Das Ergebnis ist immer der Antwort-Code 200. Der standardmäßige Fehler-Handler schreibt als Reaktion die vollständige Stacktrace in die Antwort.
In Veröffentlichungsinstanzen ist CQ WCM Debug Filter immer deaktiviert (selbst wenn er als aktiviert konfiguriert ist).
Sie können Ihre eigenen Skripte erstellen, um die Seiten anzupassen, die der Fehler-Handler anzeigt, wenn ein Fehler auftritt. Dazu verwenden Sie den standardmäßigen Überlagerungsmechanismus von AEM, damit Ihre benutzerdefinierten Seiten unter /apps
erstellt werden und die Standardseiten unter /libs
überlagert werden.
Kopieren Sie im Repository das/die Standardskript(e):
/libs/sling/servlet/errorhandler/
/apps/sling/servlet/errorhandler/
Da der Zielpfad standardmäßig nicht vorhanden ist, müssen Sie ihn erstellen, wenn Sie diesen Vorgang zum ersten Mal durchführen.
Navigieren Sie zu /apps/sling/servlet/errorhandler
. Hier können Sie entweder:
Speichern Sie die Änderungen und testen Sie sie.
Das 404.jsp
-Skript wurde speziell für die AEM-Authentifizierung entwickelt, insbesondere um die Systemanmeldung bei Auftreten dieser Fehler zu ermöglichen.
Daher sollten Sie dieses Skript nur mit größter Vorsicht ersetzen.
HTTP 500 – interner Server-Fehler zeigt einen Server-seitigen Fehler an, z. B. wenn der Server auf eine unerwartete Bedingung gestoßen ist, die ihn daran gehindert hat, die Anfrage zu erfüllen.
Wenn die Bearbeitung einer Anfrage zu einem Ausnahmefehler führt, führt das Apache Sling-Framework (auf dem AEM basiert) folgende Schritte durch:
Indem Sie die Seiten anpassen, die der Fehler-Handler zeigt, können Sie ein 500.jsp
-Skript erstellen. Es wird jedoch nur verwendet, wenn HttpServletResponse.sendError(500)
explizit ausgeführt wird, d. h. von einem Abfangalgorithmus für Ausnahmen.
Andernfalls wird der Antwort-Code auf „500“ gesetzt, aber das 500.jsp
-Skript wird nicht ausgeführt.
Um 500-Fehler zu verarbeiten, muss der Dateiname des Fehler-Handler-Skripts identisch mit der Ausnahmeklasse (oder der übergeordneten Klasse) sein. Um alle derartigen Ausnahmen zu bearbeiten, können Sie ein /apps/sling/servlet/errorhandler/Throwable.jsp
- oder /apps/sling/servlet/errorhandler/Exception.jsp
-Skript erstellen.
In Autoreninstanzen ist CQ WCM Debug Filter standardmäßig aktiviert. Das Ergebnis ist immer der Antwort-Code 200. Der standardmäßige Fehler-Handler schreibt als Reaktion die vollständige Stacktrace in die Antwort.
Für eine individuelle Fehlerverarbeitung sind Antworten mit Code 500 erforderlich. Der CQ WCM Debug-Filter muss also deaktiviert sein. Dadurch wird sichergestellt, dass der Antwort-Code 500 zurückgegeben wird, was wiederum den richtigen Sling-Fehler-Handler auslöst.
In Veröffentlichungsinstanzen ist CQ WCM Debug Filter immer deaktiviert (selbst wenn er als aktiviert konfiguriert ist).