AEM viene con un controlador de error estándar para controlar los errores HTTP; por ejemplo, mostrando:
Existen secuencias de comandos proporcionadas por el sistema (en /libs/sling/servlet/errorhandler
) para responder a códigos de error; de forma predeterminada, las siguientes están disponibles con una instancia de CQ estándar:
AEM se basa en Apache Sling, por lo tanto consulte https://sling.apache.org/site/errorhandling.html para obtener información detallada sobre la gestión de errores de Sling.
En una instancia de autor, el filtro de depuración de CQ WCM está habilitado de forma predeterminada. Esto siempre resulta en el código de respuesta 200. El controlador de error predeterminado responde escribiendo el seguimiento de pila completo en la respuesta.
En una instancia de publicación, el filtro de depuración de CQ WCM está siempre deshabilitado (aunque esté configurado como habilitado).
Puede desarrollar sus propias secuencias de comandos para personalizar las páginas que muestra el controlador de errores cuando se encuentra un error. Las páginas personalizadas se crearán en /apps
y superpondrán las páginas predeterminadas (que se encuentran en /libs
).
Consulte Uso de Overlays para obtener más detalles.
En el repositorio, copie las secuencias de comandos predeterminadas:
/libs/sling/servlet/errorhandler/
/apps/sling/servlet/errorhandler/
Como la ruta de destino no existe de forma predeterminada, deberá crearla al hacerlo por primera vez.
Ir a /apps/sling/servlet/errorhandler
. Aquí puede:
Guarde los cambios y pruebe.
Los controladores 404.jsp y 403.jsp se han diseñado específicamente para adaptarse a la autenticación CQ5; en particular, permitir el inicio de sesión del sistema en caso de estos errores.
Por lo tanto, la sustitución de estos dos controladores debe realizarse con bueno cuidado.
Los errores HTTP 500 son causados por excepciones del lado del servidor.
Cuando el procesamiento de la solicitud resulta en una excepción, el marco de Apache Sling (en el que AEM está integrado):
registra la excepción
devuelve:
en el cuerpo de la respuesta.
Al personalizar las páginas que muestra el controlador de errores se puede crear una secuencia de comandos 500.jsp
. Sin embargo, sólo se utiliza si HttpServletResponse.sendError(500)
se ejecuta explícitamente; es decir, desde un captador de excepciones.
De lo contrario, el código de respuesta se establece en 500, pero la secuencia de comandos 500.jsp
no se ejecuta.
Para gestionar errores 500, el nombre de archivo de la secuencia de comandos del controlador de errores debe ser el mismo que la clase de excepción (o superclase). Para gestionar todas estas excepciones, puede crear una secuencia de comandos /apps/sling/servlet/errorhandler/Throwable.js
p o /apps/sling/servlet/errorhandler/Exception.jsp
.
En una instancia de autor, el filtro de depuración de CQ WCM está habilitado de forma predeterminada. Esto siempre resulta en el código de respuesta 200. El controlador de error predeterminado responde escribiendo el seguimiento de pila completo en la respuesta.
Para un controlador de errores personalizado, se necesitan respuestas con código 500, por lo que el filtro de depuración de CQ WCM debe deshabilitarse. Esto garantiza que se devuelve el código de respuesta 500, que a su vez déclencheur el controlador de error Sling correcto.
En una instancia de publicación, el filtro de depuración de CQ WCM está siempre deshabilitado (aunque esté configurado como habilitado).