Hi, Am Dienstag, den 18.12.2007, 17:44 -0800 schrieb Padraic Hannon: > +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!)
I do not understand what you mean by "hierarchical resolution": Is this the Throwable class hiearchy ? If so, this is how it is currently implemented in the servlet-resolver project. Regards Felix > > -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 > >
