+1
From what I understand of your proposal this sounds great. I like the
idea of handling the 404 (or whatever) via the same request mechanism
as it would give you the same ability for script resolution you
currently have. However, I still like the idea of hierarchical
resolution, perhaps this should be worked into the basic microsling
system? Or is this an overly complicated concept? (I can see how it
could cause problems in determining exactly what should be called!)
-paddy
On Dec 17, 2007, at 11:53 PM, Felix Meschberger wrote:
Hi all,
Prompted by a proposal in the Chickens, eggs and stars thread [1], I
propose a revised error handling concept for Sling. First, though, I
present the current implementation.
Current implementation
----------------------
Currently Sling (the core project) defines a ErrorHandlerServlet. This
interface may be implemented by error handlers and registered as OSGi
services just like any plain Servlet. In case of an error
(HttpServletResponse.sendError or an uncaught Throwable), Sling core
kicks in an error handler which calls the canHandle method of each
registered servlet in turn.
For an error with status code a series of status values is checked
against the servlets until a servlet can handle. The series is defined
as ( sc, (sc/10)*10, (sc/100)*100, 0 ) e.g. for the status 413 the
series would be ( 413, 410, 400, 0 ). Sling core contains a default
error handler servlet which replies true for the last entry (0).
For an exception to be handled the class hierarchy of the exception is
checked. For a FileNotFoundException, the classes
FileNotFoundException,
IOException, Exception, and Throwable are checked. The Sling core
default error handler replies true for the Throwable class.
Proposal
--------
This implementation is working but it is rather limited as all 404
stati
are handled by the same handler regardless of the actual request.
Starting from the proposal on the dev list, we could resolve the error
handler servlet or script just like any request handling servlet or
script.
The error handler creates a temporary SlingHttpServletRequest wrapper
whose getMethod() implementation returns the status code or Throwable
thrown. With this wrapper object the same resolution process takes
place
as for a normal HTTP method. If no servlet or script can be resolved
the
default error handler is used (instead of the normal default servlet).
The call to the error handler script or servlet is done using the
unwrapped SlingHttpServletRequest, that is the getMethod returns
actual
request method. Also the usual request attributes are set as defined
in
the Servlet Specification.
A handler for a status code is only searched for the exact status
code.
A handler for a Throwable is still searched through the class
hierarchy,
which is line with catch clauses, which also support the class
hierarchy.
WDYT ?
Regards
Felix
[1]
http://www.mail-archive.com/[email protected]/msg01320.html
