I have hit this problem in the wild under CQ4.x and need to address it
in CQ5.x (so via Sling) very soon.
What about registering a node to handle error codes for path /X and
below, rather than just a script? Does that make sense?
In CQ4 the big problem that I have had is that I can't get at any
content from the error handler script directly, even though I can go
back up the tree from the non-existent resource to find content that is
meant to be served when the error occurs.
Now that I mention this, I probably could have gone direct to JCR for
the content, but that would be a big shift as everything else in that
code is ContentBus API and CQ taglib stuff.
Regards,
Jonathan 'J5' Cook
Carsten Ziegeler wrote:
Hi,
I'm wondering if something needs to be done wrt to our current error
handling. At the moment we have a global error handler (usually this is
the SlingServletResolver) which tries to find a script based on the
status code (like 404.jsp or 500.jsp).
I'm wondering if there is a need for different error handling behaviour,
like all requests to /webSiteA get a different 500.jsp as all other
requests etc.
So maybe something like a path based selection?
Or maybe something different?
WDYT?
Regards
Carsten
