Bug 34003 - provide a custom error page
Summary: provide a custom error page
Alias: None
Product: Lenya
Classification: Unclassified
Component: Miscellaneous (show other bugs)
Version: Trunk
Hardware: PC Linux
: P2 enhancement
Target Milestone: 2.0.1
Assignee: Lenya Developers
Depends on:
Reported: 2005-03-14 10:03 UTC by Joachim Wolfgang Kaltz
Modified: 2008-01-10 12:39 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Joachim Wolfgang Kaltz 2005-03-14 10:03:35 UTC
Currently, an error results in the standard Cocoon error page to be shown,
including the link saying "if you think this is a bug, contact the Cocoon
developers". Of course, such errors may simply come from a setup error, and have
nothing to do with Cocoon.

Lenya should provide a custom error page, masking the Cocoon stacktrace. This
page ideally should contain the name of the site administrator to be contacted
(this name might be an option in the local.build.properties, for example).
Furthermore, the Cocoon stacktrace could be provided as html comment, so it can
be seen in the page source, but not displayed to normal users.
Comment 1 Joachim Wolfgang Kaltz 2005-03-14 10:04:09 UTC
Note: Andreas Hartmann says: There should be a switch (debug/production) to
enable/disable the Cocoon error screen (which is IMO very convenient).
Comment 2 Gregor J. Rothfuss 2005-06-04 18:42:33 UTC
we now have only one general, fallback-enabled error handling pipeline on trunk
(which makes customization a snap), and the error screens are I18N-enabled.

now we only need to do the desired build-time substitutions (to be determined)
Comment 3 Andreas Hartmann 2007-10-29 08:59:43 UTC
It would also be important to provide a 404 in the layout of the default
publication, including the navigation widgets.
Comment 4 Andreas Hartmann 2007-10-29 11:14:08 UTC
(In reply to comment #3)
> It would also be important to provide a 404 in the layout of the default
> publication, including the navigation widgets.

Done in revision 589779.
Comment 5 Andreas Hartmann 2007-10-29 15:25:21 UTC
The error handling is now done in a separate sitemap which is overridden in the
default publication. Is this sufficient to give an example?
Comment 6 J 2007-11-04 12:16:41 UTC
i came across a problem with the new error handling: i'm playing around with
allowing servlet reloads in web.xml (you can then use the "cocoon-reload"
request parameter to restart the servlet - i was hoping that this could speed up
changes needing re-deployment or that it can be used to reset profiling

now, when you try to do that, you end up with:

Message: You cannot lookup components on a disposed ComponentLocator

Description: org.apache.cocoon.sitemap.PatternException: Cannot get variable
'error.xmap' in expression '{fallback:error.xmap}'

i.e. the sitemap stays in effect although the servlet has been killed. now this
is certainly a corner case, but the question remains whether the error handler
should depend on anything as high-level as the fallback protocol... but it's oh
so convenient...