You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2007/12/18 08:53:35 UTC
Error Handling in Sling
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/sling-dev@incubator.apache.org/msg01320.html
Re: Error Handling in Sling
Posted by Felix Meschberger <fm...@gmail.com>.
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 <fm...@gmail.com> 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/sling-dev@incubator.apache.org/msg01320.html
> > >
> > >
> >
> >
>
>
Re: Error Handling in Sling
Posted by Michael Marth <mm...@day.com>.
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 <fm...@gmail.com> 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/sling-dev@incubator.apache.org/msg01320.html
> >
> >
>
>
--
Michael Marth, http://dev.day.com
Re: Error Handling in Sling
Posted by Felix Meschberger <fm...@gmail.com>.
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/sling-dev@incubator.apache.org/msg01320.html
>
>
Re: Error Handling in Sling
Posted by Padraic Hannon <pi...@wasabicowboy.com>.
+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/sling-dev@incubator.apache.org/msg01320.html
Re: Error Handling in Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Am Dienstag, den 18.12.2007, 17:19 +0100 schrieb Bertrand Delacretaz:
> On Dec 18, 2007 4:37 PM, Felix Meschberger <fm...@gmail.com> wrote:
>
> > ...we could make it even simpler: we just
> > look for an "error" script or servlet, like this:
> >
> > Servlet s = resolveScriptOrServlet("error");
> > if (s == null) {
> > s = defaultErrorHandlerServlet;
> > }...
>
> And let the script decide based on the status code and/or Throwable?
>
> I'd be ok with that if the script has a way to delegate to the default
> handler, say:
>
> if(httpStatus == 404 ) {
> // handle this here
> } else {
> delegateTodefaultErrorHandlerServlet();
> }
>
> Where delegateTodefaultErrorHandlerServlet could be just a forward to
> the default handler servlet, right?
As we use plain old script resolution to find the error handler, it
might also be conceivable, that we would want a less specific error
handler for non-404 errors etc. given all these special cases, that
might come up, I would rather get back to my initial proposal of having
per-status code handlers and per-throwable (supporting class hierarchy)
handlers.
Regards
Felix
Re: Error Handling in Sling
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Dec 18, 2007 4:37 PM, Felix Meschberger <fm...@gmail.com> wrote:
> ...we could make it even simpler: we just
> look for an "error" script or servlet, like this:
>
> Servlet s = resolveScriptOrServlet("error");
> if (s == null) {
> s = defaultErrorHandlerServlet;
> }...
And let the script decide based on the status code and/or Throwable?
I'd be ok with that if the script has a way to delegate to the default
handler, say:
if(httpStatus == 404 ) {
// handle this here
} else {
delegateTodefaultErrorHandlerServlet();
}
Where delegateTodefaultErrorHandlerServlet could be just a forward to
the default handler servlet, right?
-Bertrand
Re: Error Handling in Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Am Dienstag, den 18.12.2007, 15:45 +0100 schrieb Bertrand Delacretaz:
> On Dec 18, 2007 3:42 PM, Felix Meschberger <fm...@gmail.com> wrote:
> > Am Dienstag, den 18.12.2007, 15:29 +0100 schrieb Tobias Bocanegra:
> > > that why i wouldn't check for a exception script at all. since any
> > > exception would result in a 500 that is where the script is then used.
> > > or what other internal errors do you except ?
> >
> > Just as you might want to handle status codes differently, you might
> > want to handle different exceptions differently ...
>
> But if the Exception is made available to error handlers (which is a
> good idea anyway), we could say that Exceptions are handled by the 500
> handler, which decides what to do.
Hmm, thinking along those lines, we could make it even simpler: we just
look for an "error" script or servlet, like this:
Servlet s = resolveScriptOrServlet("error");
if (s == null) {
s = defaultErrorHandlerServlet;
}
Because as defined by the Servlet Spec the Throwable or status code is
made available as request attributes [1].
Regards
Felix
[1] http://incubator.apache.org/sling/site/component-api.html#ComponentAPI-ErrorHandling
Re: Error Handling in Sling
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Dec 18, 2007 3:42 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Am Dienstag, den 18.12.2007, 15:29 +0100 schrieb Tobias Bocanegra:
> > that why i wouldn't check for a exception script at all. since any
> > exception would result in a 500 that is where the script is then used.
> > or what other internal errors do you except ?
>
> Just as you might want to handle status codes differently, you might
> want to handle different exceptions differently ...
But if the Exception is made available to error handlers (which is a
good idea anyway), we could say that Exceptions are handled by the 500
handler, which decides what to do.
-Bertrand
Re: Error Handling in Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Am Dienstag, den 18.12.2007, 15:29 +0100 schrieb Tobias Bocanegra:
> that why i wouldn't check for a exception script at all. since any
> exception would result in a 500 that is where the script is then used.
> or what other internal errors do you except ?
Just as you might want to handle status codes differently, you might
want to handle different exceptions differently ...
Regards
Felix
>
> regards, toby
>
> On 12/18/07, Lars Trieloff <la...@trieloff.net> wrote:
> > I agree. It is also easier to explain that we walk up the class
> > hierarchy up to Throwable, then go to 500.js and then use the default.
> > Compare to "We walk up the class hierarchy, but before we actually
> > meet Throwable, we use 500.js instead. If this does not work, we use
> > the default."
> >
> > Lars
> >
> > On 18.12.2007, at 14:26, Felix Meschberger wrote:
> >
> > > Am Dienstag, den 18.12.2007, 14:12 +0100 schrieb Tobias Bocanegra:
> > >> i don't think that other than a 500.js is needed. or do you have a
> > >> valid use case?
> > >
> > > Not a use case really, but staying in the line: using 500 for a
> > > Throwable is bridging from an exception over to a status code.
> > > Therefore, I would rather like to stay with the Throwable in the first
> > > place.
> > >
> > > Checking for 500 afterwards, sounds reasonable as kind of a catch-all
> > >
> > > Regards
> > > Felix
> > >
> > >> regards, toby
> > >>
> > >> On 12/18/07, Lars Trieloff <la...@trieloff.net> wrote:
> > >>> I would prefer simple names over FQ names, but perhaps checking
> > >>> the FQ
> > >>> name first and then the SimpleName would allow us to eliminate all
> > >>> ambiguity.
> > >>>
> > >>> regards,
> > >>>
> > >>> Lars
> > >>>
> > >>> On 18.12.2007, at 13:28, Bertrand Delacretaz wrote:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>> On Dec 18, 2007 1:16 PM, Felix Meschberger <fm...@gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>>> ...(1) for status codes:...
> > >>>>
> > >>>> I assume you mean status codes >= 400, right?
> > >>>>
> > >>>> I'm ok with the proposed ScriptOrServlet resolution.
> > >>>>
> > >>>>> ...(2) Likewise for Throwables it would be:
> > >>>>>
> > >>>>> Class<?> tClass = throwable.getClass();
> > >>>>> Servlet s = null;
> > >>>>> while (s == null && tClass != Object.class) {
> > >>>>> s = resolveScriptOrServlet(tClass);,,,
> > >>>>
> > >>>> Shouldn't we use Class.getSimpleName() here?So that scripts are
> > >>>> named
> > >>>> MyFunnyException instead of
> > >>>> com.nowhere.somepackage.MyFunnyException?
> > >>>>
> > >>>>> tClass = tClass.getSuperclass();
> > >>>>> }
> > >>>>> if (s == null) {
> > >>>>> s = defaultErrorHandlerServlet;
> > >>>>> }...
> > >>>>
> > >>>> Sounds good to me, but we'll have to be careful with exceptions
> > >>>> that
> > >>>> occur while looking up exception scripts (I'm kind of noting the
> > >>>> obvious here ;-)
> > >>>>
> > >>>> -Bertrand
> > >>>
> > >>> --
> > >>> Lars Trieloff
> > >>> lars@trieloff.net
> > >>> http://weblogs.goshaky.com/weblogs/lars
> > >>>
> > >>>
> > >>
> > >>
> > >
> >
> > --
> > Lars Trieloff
> > lars@trieloff.net
> > http://weblogs.goshaky.com/weblogs/lars
> >
> >
>
>
Re: Error Handling in Sling
Posted by Tobias Bocanegra <to...@day.com>.
that why i wouldn't check for a exception script at all. since any
exception would result in a 500 that is where the script is then used.
or what other internal errors do you except ?
regards, toby
On 12/18/07, Lars Trieloff <la...@trieloff.net> wrote:
> I agree. It is also easier to explain that we walk up the class
> hierarchy up to Throwable, then go to 500.js and then use the default.
> Compare to "We walk up the class hierarchy, but before we actually
> meet Throwable, we use 500.js instead. If this does not work, we use
> the default."
>
> Lars
>
> On 18.12.2007, at 14:26, Felix Meschberger wrote:
>
> > Am Dienstag, den 18.12.2007, 14:12 +0100 schrieb Tobias Bocanegra:
> >> i don't think that other than a 500.js is needed. or do you have a
> >> valid use case?
> >
> > Not a use case really, but staying in the line: using 500 for a
> > Throwable is bridging from an exception over to a status code.
> > Therefore, I would rather like to stay with the Throwable in the first
> > place.
> >
> > Checking for 500 afterwards, sounds reasonable as kind of a catch-all
> >
> > Regards
> > Felix
> >
> >> regards, toby
> >>
> >> On 12/18/07, Lars Trieloff <la...@trieloff.net> wrote:
> >>> I would prefer simple names over FQ names, but perhaps checking
> >>> the FQ
> >>> name first and then the SimpleName would allow us to eliminate all
> >>> ambiguity.
> >>>
> >>> regards,
> >>>
> >>> Lars
> >>>
> >>> On 18.12.2007, at 13:28, Bertrand Delacretaz wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> On Dec 18, 2007 1:16 PM, Felix Meschberger <fm...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> ...(1) for status codes:...
> >>>>
> >>>> I assume you mean status codes >= 400, right?
> >>>>
> >>>> I'm ok with the proposed ScriptOrServlet resolution.
> >>>>
> >>>>> ...(2) Likewise for Throwables it would be:
> >>>>>
> >>>>> Class<?> tClass = throwable.getClass();
> >>>>> Servlet s = null;
> >>>>> while (s == null && tClass != Object.class) {
> >>>>> s = resolveScriptOrServlet(tClass);,,,
> >>>>
> >>>> Shouldn't we use Class.getSimpleName() here?So that scripts are
> >>>> named
> >>>> MyFunnyException instead of
> >>>> com.nowhere.somepackage.MyFunnyException?
> >>>>
> >>>>> tClass = tClass.getSuperclass();
> >>>>> }
> >>>>> if (s == null) {
> >>>>> s = defaultErrorHandlerServlet;
> >>>>> }...
> >>>>
> >>>> Sounds good to me, but we'll have to be careful with exceptions
> >>>> that
> >>>> occur while looking up exception scripts (I'm kind of noting the
> >>>> obvious here ;-)
> >>>>
> >>>> -Bertrand
> >>>
> >>> --
> >>> Lars Trieloff
> >>> lars@trieloff.net
> >>> http://weblogs.goshaky.com/weblogs/lars
> >>>
> >>>
> >>
> >>
> >
>
> --
> Lars Trieloff
> lars@trieloff.net
> http://weblogs.goshaky.com/weblogs/lars
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: Error Handling in Sling
Posted by Lars Trieloff <la...@trieloff.net>.
I agree. It is also easier to explain that we walk up the class
hierarchy up to Throwable, then go to 500.js and then use the default.
Compare to "We walk up the class hierarchy, but before we actually
meet Throwable, we use 500.js instead. If this does not work, we use
the default."
Lars
On 18.12.2007, at 14:26, Felix Meschberger wrote:
> Am Dienstag, den 18.12.2007, 14:12 +0100 schrieb Tobias Bocanegra:
>> i don't think that other than a 500.js is needed. or do you have a
>> valid use case?
>
> Not a use case really, but staying in the line: using 500 for a
> Throwable is bridging from an exception over to a status code.
> Therefore, I would rather like to stay with the Throwable in the first
> place.
>
> Checking for 500 afterwards, sounds reasonable as kind of a catch-all
>
> Regards
> Felix
>
>> regards, toby
>>
>> On 12/18/07, Lars Trieloff <la...@trieloff.net> wrote:
>>> I would prefer simple names over FQ names, but perhaps checking
>>> the FQ
>>> name first and then the SimpleName would allow us to eliminate all
>>> ambiguity.
>>>
>>> regards,
>>>
>>> Lars
>>>
>>> On 18.12.2007, at 13:28, Bertrand Delacretaz wrote:
>>>
>>>> Hi,
>>>>
>>>> On Dec 18, 2007 1:16 PM, Felix Meschberger <fm...@gmail.com>
>>>> wrote:
>>>>
>>>>> ...(1) for status codes:...
>>>>
>>>> I assume you mean status codes >= 400, right?
>>>>
>>>> I'm ok with the proposed ScriptOrServlet resolution.
>>>>
>>>>> ...(2) Likewise for Throwables it would be:
>>>>>
>>>>> Class<?> tClass = throwable.getClass();
>>>>> Servlet s = null;
>>>>> while (s == null && tClass != Object.class) {
>>>>> s = resolveScriptOrServlet(tClass);,,,
>>>>
>>>> Shouldn't we use Class.getSimpleName() here?So that scripts are
>>>> named
>>>> MyFunnyException instead of
>>>> com.nowhere.somepackage.MyFunnyException?
>>>>
>>>>> tClass = tClass.getSuperclass();
>>>>> }
>>>>> if (s == null) {
>>>>> s = defaultErrorHandlerServlet;
>>>>> }...
>>>>
>>>> Sounds good to me, but we'll have to be careful with exceptions
>>>> that
>>>> occur while looking up exception scripts (I'm kind of noting the
>>>> obvious here ;-)
>>>>
>>>> -Bertrand
>>>
>>> --
>>> Lars Trieloff
>>> lars@trieloff.net
>>> http://weblogs.goshaky.com/weblogs/lars
>>>
>>>
>>
>>
>
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: Error Handling in Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Am Dienstag, den 18.12.2007, 14:12 +0100 schrieb Tobias Bocanegra:
> i don't think that other than a 500.js is needed. or do you have a
> valid use case?
Not a use case really, but staying in the line: using 500 for a
Throwable is bridging from an exception over to a status code.
Therefore, I would rather like to stay with the Throwable in the first
place.
Checking for 500 afterwards, sounds reasonable as kind of a catch-all
Regards
Felix
> regards, toby
>
> On 12/18/07, Lars Trieloff <la...@trieloff.net> wrote:
> > I would prefer simple names over FQ names, but perhaps checking the FQ
> > name first and then the SimpleName would allow us to eliminate all
> > ambiguity.
> >
> > regards,
> >
> > Lars
> >
> > On 18.12.2007, at 13:28, Bertrand Delacretaz wrote:
> >
> > > Hi,
> > >
> > > On Dec 18, 2007 1:16 PM, Felix Meschberger <fm...@gmail.com> wrote:
> > >
> > >> ...(1) for status codes:...
> > >
> > > I assume you mean status codes >= 400, right?
> > >
> > > I'm ok with the proposed ScriptOrServlet resolution.
> > >
> > >> ...(2) Likewise for Throwables it would be:
> > >>
> > >> Class<?> tClass = throwable.getClass();
> > >> Servlet s = null;
> > >> while (s == null && tClass != Object.class) {
> > >> s = resolveScriptOrServlet(tClass);,,,
> > >
> > > Shouldn't we use Class.getSimpleName() here?So that scripts are named
> > > MyFunnyException instead of com.nowhere.somepackage.MyFunnyException?
> > >
> > >> tClass = tClass.getSuperclass();
> > >> }
> > >> if (s == null) {
> > >> s = defaultErrorHandlerServlet;
> > >> }...
> > >
> > > Sounds good to me, but we'll have to be careful with exceptions that
> > > occur while looking up exception scripts (I'm kind of noting the
> > > obvious here ;-)
> > >
> > > -Bertrand
> >
> > --
> > Lars Trieloff
> > lars@trieloff.net
> > http://weblogs.goshaky.com/weblogs/lars
> >
> >
>
>
Re: Error Handling in Sling
Posted by Tobias Bocanegra <to...@day.com>.
i don't think that other than a 500.js is needed. or do you have a
valid use case?
i would do the 500.js and maybe add the throwable.js if we really need it.
regards, toby
On 12/18/07, Lars Trieloff <la...@trieloff.net> wrote:
> I would prefer simple names over FQ names, but perhaps checking the FQ
> name first and then the SimpleName would allow us to eliminate all
> ambiguity.
>
> regards,
>
> Lars
>
> On 18.12.2007, at 13:28, Bertrand Delacretaz wrote:
>
> > Hi,
> >
> > On Dec 18, 2007 1:16 PM, Felix Meschberger <fm...@gmail.com> wrote:
> >
> >> ...(1) for status codes:...
> >
> > I assume you mean status codes >= 400, right?
> >
> > I'm ok with the proposed ScriptOrServlet resolution.
> >
> >> ...(2) Likewise for Throwables it would be:
> >>
> >> Class<?> tClass = throwable.getClass();
> >> Servlet s = null;
> >> while (s == null && tClass != Object.class) {
> >> s = resolveScriptOrServlet(tClass);,,,
> >
> > Shouldn't we use Class.getSimpleName() here?So that scripts are named
> > MyFunnyException instead of com.nowhere.somepackage.MyFunnyException?
> >
> >> tClass = tClass.getSuperclass();
> >> }
> >> if (s == null) {
> >> s = defaultErrorHandlerServlet;
> >> }...
> >
> > Sounds good to me, but we'll have to be careful with exceptions that
> > occur while looking up exception scripts (I'm kind of noting the
> > obvious here ;-)
> >
> > -Bertrand
>
> --
> Lars Trieloff
> lars@trieloff.net
> http://weblogs.goshaky.com/weblogs/lars
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: Error Handling in Sling
Posted by Lars Trieloff <la...@trieloff.net>.
I would prefer simple names over FQ names, but perhaps checking the FQ
name first and then the SimpleName would allow us to eliminate all
ambiguity.
regards,
Lars
On 18.12.2007, at 13:28, Bertrand Delacretaz wrote:
> Hi,
>
> On Dec 18, 2007 1:16 PM, Felix Meschberger <fm...@gmail.com> wrote:
>
>> ...(1) for status codes:...
>
> I assume you mean status codes >= 400, right?
>
> I'm ok with the proposed ScriptOrServlet resolution.
>
>> ...(2) Likewise for Throwables it would be:
>>
>> Class<?> tClass = throwable.getClass();
>> Servlet s = null;
>> while (s == null && tClass != Object.class) {
>> s = resolveScriptOrServlet(tClass);,,,
>
> Shouldn't we use Class.getSimpleName() here?So that scripts are named
> MyFunnyException instead of com.nowhere.somepackage.MyFunnyException?
>
>> tClass = tClass.getSuperclass();
>> }
>> if (s == null) {
>> s = defaultErrorHandlerServlet;
>> }...
>
> Sounds good to me, but we'll have to be careful with exceptions that
> occur while looking up exception scripts (I'm kind of noting the
> obvious here ;-)
>
> -Bertrand
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: Error Handling in Sling
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Dec 18, 2007 1:16 PM, Felix Meschberger <fm...@gmail.com> wrote:
> ...(1) for status codes:...
I assume you mean status codes >= 400, right?
I'm ok with the proposed ScriptOrServlet resolution.
> ...(2) Likewise for Throwables it would be:
>
> Class<?> tClass = throwable.getClass();
> Servlet s = null;
> while (s == null && tClass != Object.class) {
> s = resolveScriptOrServlet(tClass);,,,
Shouldn't we use Class.getSimpleName() here?So that scripts are named
MyFunnyException instead of com.nowhere.somepackage.MyFunnyException?
> tClass = tClass.getSuperclass();
> }
> if (s == null) {
> s = defaultErrorHandlerServlet;
> }...
Sounds good to me, but we'll have to be careful with exceptions that
occur while looking up exception scripts (I'm kind of noting the
obvious here ;-)
-Bertrand
Re: Error Handling in Sling
Posted by Lars Trieloff <la...@trieloff.net>.
>
My idea is:
> So, the resolution process would be :
>
> (1) for status codes:
>
> Servlet s = resolveScriptOrServlet(code);
> if (s == null) {
> s = resolveScriptOrServlet(500);
> }
> if (s == null) {
> s = defaultErrorHandlerServlet;
> }
>
> (2) Likewise for Throwables it would be:
>
> Class<?> tClass = throwable.getClass();
> Servlet s = null;
> while (s == null && tClass != Object.class) {
> s = resolveScriptOrServlet(tClass);
> tClass = tClass.getSuperclass();
> }
if (s == null) {
s= resolveScriptOrServlet(500);
}
>
> if (s == null) {
> s = defaultErrorHandlerServlet;
> }
so you do not have to create a Throwable.js, but can re-use your 500.js
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: Error Handling in Sling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 18.12.2007, 12:47 +0100 schrieb Lars Trieloff:
> Sounds good to me, but I would make 500.js and Throwable.js (as the
> catch-all-solution) interchangeable, because having GET.js PUT.js
> DELETE.js POST.js 404.js 401.js and Throwable.js looks like breaking a
> pattern if you just need unspecific, but user-friendly error handling.
So, the resolution process would be :
(1) for status codes:
Servlet s = resolveScriptOrServlet(code);
if (s == null) {
s = resolveScriptOrServlet(500);
}
if (s == null) {
s = defaultErrorHandlerServlet;
}
(2) Likewise for Throwables it would be:
Class<?> tClass = throwable.getClass();
Servlet s = null;
while (s == null && tClass != Object.class) {
s = resolveScriptOrServlet(tClass);
tClass = tClass.getSuperclass();
}
if (s == null) {
s = defaultErrorHandlerServlet;
}
Right ?
Regards
Felix
>
> regards,
>
> Lars
>
> On 18.12.2007, at 08:53, 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/sling-dev@incubator.apache.org/msg01320.html
> >
>
> --
> Lars Trieloff
> lars@trieloff.net
> http://weblogs.goshaky.com/weblogs/lars
>
Re: Error Handling in Sling
Posted by Lars Trieloff <la...@trieloff.net>.
Sounds good to me, but I would make 500.js and Throwable.js (as the
catch-all-solution) interchangeable, because having GET.js PUT.js
DELETE.js POST.js 404.js 401.js and Throwable.js looks like breaking a
pattern if you just need unspecific, but user-friendly error handling.
regards,
Lars
On 18.12.2007, at 08:53, 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/sling-dev@incubator.apache.org/msg01320.html
>
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars