- Implementing Applications for AEM as a Cloud Service
- Using Cloud Manager
- Managing Environments
- Configuring your CI/CD Pipeline
- Deploying your Code
- Understanding your Test Results
- Accessing and Managing Logs
- Understanding Notifications
- Managing SSL Certificates
- Managing Custom Domain Names
- Introduction
- Getting a Custom Domain Name
- Adding a Custom Domain Name
- Adding a TXT Record
- Checking Custom Domain Name Status
- Configuring DNS Settings
- Checking DNS Record Status
- Viewing & Updating & Replacing a Custom Domain Name
- Updating a Custom Domain Name’s SSL Certificate
- Deleting a Custom Domain Name
- Managing IP Allow Lists
- Cloud Manager FAQs
- Managing your Code
- Developing for AEM as a Cloud Service
- AEM Project Structure
- AEM Project Repository Structure Package
- AEM as a Cloud Service SDK
- AEM as a Cloud Service Development Guidelines
- Logging
- Configurations and the Configuration Browser
- AEM Technical Foundations
- AEM as a Cloud Service API
- Generating Access Tokens for Server Side APIs
- Headless Developer Journey
- Headful and Headless in AEM
- Full Stack AEM Development
- Getting Started Developing AEM Sites - WKND Tutorial
- Structure of the AEM UI
- Sling Cheatsheet
- Using Sling Adapters
- Using the Sling Resource Merger in AEM as a Cloud Service
- Overlays in AEM as a Cloud Service
- Using Client-Side Libraries
- Page Diff
- Editor Limitations
- Naming Conventions
- Components and Templates
- AEM Tagging Framework
- Building Tagging into AEM Applications
- Search
- Custom Error Pages
- AEM Node Types
- Java API Guidelines
- Hybrid AEM Development
- Hybrid and SPA with AEM
- Enabling JSON Export for a Component
- SPA Introduction and Walkthrough
- SPA WKND Tutorial
- Getting Started using React
- Getting Started using Angular
- SPA Deep Dives
- Developing SPAs for AEM
- SPA Editor Overview
- SPA Blueprint
- SPA Page Component
- Dynamic Model to Component Mapping
- Model Routing
- The RemotePage Component
- Editing an External SPA within AEM
- Composite Components in SPAs
- Server Side Rendering
- Enabling JSON Export for a Component
- Launch Integration
- SPA Reference Documents
- Headless Experience Management
- Headless and AEM
- Getting Started Guides
- Content Fragments
- Headless Delivery with Content Fragments and GraphQL
- Working with Content Fragments
- Enable Content Fragment Functionality for your Instance
- Content Fragment Models
- Managing Content Fragments
- Variations - Authoring Fragment Content
- Markdown
- Using Associated Content
- Metadata - Fragment Properties
- Structure Tree
- Preview - JSON Representation
- Delivery API
- Developer Tools
- Personalization
- Configuring and Extending AEM as a Cloud Service
- Deploying to AEM as a Cloud Service
- Author Tier
- Content Delivery Overview
Customizing Error Pages
AEM comes with a standard error handler for handling HTTP errors; for example, by showing:
To respond to errors, AEM provides a 404.jsp script under /libs/sling/servlet/errorhandler.
Because AEM is based on Apache Sling, further information is available in the Apache error handling documentation.
On an author instance, CQ WCM Debug Filter is enabled by default. This always results in the response code 200. The default error handler responds by writing the full stack trace to the response.
On a publish instance, CQ WCM Debug Filter is always disabled (even if configured as enabled).
How to Customize Pages Shown by the Error Handler
You can develop your own scripts to customize the pages shown by the error handler when an error is encountered. To do this you will leverage AEM’s standard overlay mechanism so that your customized pages are created under /apps and overlay the default pages that are under /libs.
-
In the repository, copy the default script(s):
- from
/libs/sling/servlet/errorhandler/ - to
/apps/sling/servlet/errorhandler/
The destination path does not exist by default, so you will need to create it when doing this for the first time.
- from
-
Navigate to
/apps/sling/servlet/errorhandler. Here you can either:- edit the appropriate existing script to supply the information required. Or
- create, and edit, a new script for the required code.
-
Save the changes and test.
The 404.jsp script has been specifically designed to cater to AEM authentication; in particular, to allow for system login in the case of these errors.
Therefore, replacement of this script should be done with great care.
Customizing the Response to HTTP 500 Errors
The HTTP 500 Internal Server Error indicates a server-side error such as the server encountering an unexpected condition which prevented it from fulfilling the request.
When request processing results in an exception, the Apache Sling framework (which AEM is built on):
- Logs the exception
- And returns in the body of the response:
- The HTTP response code 500
- The exception stack trace
By customizing the pages shown by the error handler a 500.jsp script can be created. However, it is only used if HttpServletResponse.sendError(500) is executed explicitly; i.e. from an exception catcher.
Otherwise, the response code is set to 500, but the 500.jsp script is not executed.
To handle 500 errors, the file name of the error handler script must be the same as the exception class (or superclass). To handle all such exceptions you can create a script /apps/sling/servlet/errorhandler/Throwable.jsp or /apps/sling/servlet/errorhandler/Exception.jsp.
On an author instance, CQ WCM Debug Filter is enabled by default. This always results in the response code 200. The default error handler responds by writing the full stack trace to the response.
For a custom error-handler, responses with code 500 are needed - so the CQ WCM Debug Filter needs to be disabled. This ensures that the response code 500 is returned, which in turn triggers the correct Sling error-handler.
On a publish instance, CQ WCM Debug Filter is always disabled (even if configured as enabled).
Resources on adobe.com
Resources
Adobe Account
