Anpassen von Fehlerseiten

AEM enthält einen Standard-Fehler-Handler für die Verarbeitung von HTTP-Fehlern. Beispielsweise wird Folgendes gezeigt:

Standardfehlermeldung

Um auf Fehler zu reagieren, stellt AEM unter /libs/sling/servlet/errorhandler ein 404.jsp-Skript bereit.

TIPP

Da AEM auf Apache Sling basiert, sind weitere Informationen in der Apache-Dokumentation zur Fehlerbehandlung verfügbar.

HINWEIS

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

Anpassen der vom Fehler-Handler angezeigten Seiten

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.

  1. Kopieren Sie im Repository das/die Standardskript(e):

    • von /libs/sling/servlet/errorhandler/
    • in /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.

  2. Navigieren Sie zu /apps/sling/servlet/errorhandler. Hier können Sie entweder:

    • das entsprechende vorhandene Skript bearbeiten, um die benötigten Informationen anzugeben. Oder
    • ein neues Skript für den erforderlichen Code erstellen und bearbeiten.

  3. Speichern Sie die Änderungen und testen Sie sie.

VORSICHT

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.

Anpassung der Reaktion auf HTTP 500-Fehler

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:

  • Protokolliert den Ausnahmefehler
  • Gibt Folgendes im Antworttext zurück:
    • den HTTP-Antwort-Code 500
    • den Stacktrace des Ausnahmefehlers

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.

VORSICHT

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

Auf dieser Seite