Hi Michael, Am Donnerstag, den 20.12.2007, 16:59 +0100 schrieb Michael Marth: > you might have lost me in this discussion, but may I ask anyway:
Hm, I thought it would be clear from my description :-) > We now have three orthogonal pieces in resolving a script: http method, > requested mime type and response status code (plus script language). How do > they get mixed in the script resolution process? Which script will be > executed when there is a request for a *.pdf that results in a 404? Is it > 404.pdf.esp or 404.esp or sthg else? Actually, it is 404.*. The error handler will look for a script providing a request object whose method is set to the status code or simple Throwable class name when looking for the handler script. So, as 404 (or whatever) is not GET or HEAD, the method name is used as the script name. Regards Felix > > thanks for clarifying > Michael > > On 12/20/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > 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 > > > > > > > > > > > >
