Benutzerdefinierte Fehler-Handler-Seiten | AEM

Um in der Adobe Experience Manager benutzerdefinierte Fehler-Handler zum Rendern verschiedener HTTP-Fehler einzurichten, kopieren Sie das benutzerdefinierte Skript aus /libs/sling/servlet/errorhandler an denselben Speicherort unter /apps.

Beschreibung description

Umgebung

Adobe Experience Manager

Problem/Symptome

Wie werden benutzerdefinierte Skripte oder Fehler-Handler erstellt, die unterschiedliche HTTP-Fehler rendern?

Auflösung resolution

Die standardmäßigen Fehler-Handler-Skripte befinden sich unter /libs/sling/servlet/errorhandler.

Sie können die standardmäßige Fehlerbehandlung überlagern, indem Sie das Skript, das Sie anpassen möchten, aus /libs/sling/servlet/errorhandler an denselben Speicherort unter /apps (d. h. /apps/sling/servlet/errorhandler) kopieren. Erstellen Sie diesen Pfad, wenn er nicht existiert (standardmäßig nicht).

Sie können beispielsweise die Behandlung von 404-Fehlern anpassen, indem Sie /libs/sling/servlet/errorhandler/404.jsp nach /apps/sling/servlet/errorhandler/404.jsp kopieren

Die HTTP 500-Fehler werden durch Server-seitige Ausnahmen verursacht. Wenn die Anforderungsverarbeitung zu einer Ausnahme führt, basiert das Apache Sling Framework CQ auf Protokollen der Ausnahme und gibt HTTP-Fehler-Code 500 und die Ausnahme-Stack-Ablaufverfolgung im Hauptteil der Antwort zurück.

Um 500 Fehler zu verarbeiten, muss der Dateiname eines Fehler-Handler-Skripts mit dem der Ausnahmeklasse (oder der übergeordneten Klasse) übereinstimmen. Um beispielsweise alle Ausnahmen zu verarbeiten, erstellen Sie ein /apps/sling/servlet/errorhandler/Throwable.jsp.

Weitere Informationen finden Sie ​ „Sling-".

Hinweis: Die Datei 500.jsp wird nur verwendet, wenn HttpServletResponse.sendError(500) explizit, d. h. von einem Ausnahmefänger, ausgeführt wird. Andernfalls wird nur der Antwort-Code auf 500 festgelegt, aber die 500.jsp wird nicht ausgeführt. In diesem Fall können Sie eine ".jsp“, um alle diese Ausnahmen zu verarbeiten.

Hinweis: In einer Autoreninstanz ist der CQ WCM Debug-Filter standardmäßig aktiviert. Dies führt immer zu einem Antwort-Code 200, und der standardmäßige ErrorHandler wird verwendet, der die vollständige Stacktrace-Verfolgung in die Antwort schreibt. In Veröffentlichungsinstanzen ist der CQ WCM Debug-Filter immer deaktiviert (auch wenn er aktiviert sein soll).