Guys, you might have lost me in this discussion, but may I ask anyway:
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? 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 > > > > > > -- Michael Marth, http://dev.day.com
