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.
Note: Andreas Hartmann says: There should be a switch (debug/production) to enable/disable the Cocoon error screen (which is IMO very convenient).
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)
It would also be important to provide a 404 in the layout of the default publication, including the navigation widgets.
(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.
The error handling is now done in a separate sitemap which is overridden in the default publication. Is this sufficient to give an example?
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 information). 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...