You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Björn Lütkemeier <bl...@s-und-n.de> on 2003/04/07 10:52:36 UTC
Extending error handling
Hi,
for a customer we need two extensions to the current error handling in
Cocoon. Since we think, that this extensions may be of general interest in
Cocoon, we'd like to ask what you think about it? Thanks for answers!
1) Possibility to define a "hierarchy" of error handlers: pipeline -
subsitemap - sitemap. The behaviour is expected to be the following: When an
exception occurs, Cocoon shall check whether a handler has been defined for
the requested resource's pipeline, that is able to handle this specific
error. If such a handler does not exist, a handler responsible for the whole
subsitemap is searched. If it also does not exists, an over-all default
handler, defined in the root sitemap, would be used.
Our idea now is to extend the tag <map:pipelines> for being able to contain
<map:handle-errors> tags and add the above behaviour to the treeprocessor.
This allows handler's to be defined for the hierarchy levels subsitemap and
sitemap:
Sitemap:
<map:pipelines>
<map:pipeline>
<map:mount src=subsitemap/>
</map:pipeline>
...
<map:handle-errors> <!-- default handler for whole system -->
...
</map:handle-errors>
</map:pipelines>
Subsitemap:
<map:pipelines>
<map:pipeline>
...
<map:handle-errors> <!-- handler for pipeline -->
...
</map:handle-errors>
</map:pipeline>
...
<map:handle-errors> <!-- handler for whole subsitemap -->
...
</map:handle-errors>
</map:pipelines>
2) Each error handler shall not only regard the type of the occured
exception for the decision, whether he is responsible for it, but further
properties like error codes etc., that are accessible via bean-style methods
in the exception object.
Our idea for this is to extend the new
org.apache.cocoon.selection.ExceptionSelector, so that an error handler
definition could look like:
<map:selector name="exception"
src="org.apache.cocoon.selection.ExceptionSelector">
<exception name=myexc1 class=example.MyException1/>
<exception name=myexc2 class=example.MyException2/>
</map:selector>
...
<map:pipeline>
...
<map:handle-errors>
<map:select type=exception>
<map:when test=type=myexc1,errorCode=10>
...
</map:when>
<map:when test=type=myexc2,errorCode=20>
...
</map:when>
</map:select>
</map:handle-errors>
</map:pipeline>
In this case the exception classes example.MyException1 and
example.MyException2 are expected to have a method getErrorCode() which is
called via reflection from within the selector.
One could also think about allowing more complex expression within the test
attribute like (type=myexc1 and errorCode>=10 and errorCode<20) etc.
Any comments?
Regards, Bjoern.
--------------------------------------------
S&N AG
Klingender Str. 5
D-33100 Paderborn
--------------------------------------------
internet: http://www.s-und-n.de
mail: bluetkemeier@s-und-n.de
phone: 05251 / 1581-35
--------------------------------------------
Re: Extending error handling
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/7/03 10:52 AM Björn Lütkemeier wrote:
> Hi,
>
> for a customer we need two extensions to the current error handling in
> Cocoon. Since we think, that this extensions may be of general interest in
> Cocoon, we'd like to ask what you think about it? Thanks for answers!
>
> 1) Possibility to define a "hierarchy" of error handlers: pipeline -
> subsitemap - sitemap. The behaviour is expected to be the following: When an
> exception occurs, Cocoon shall check whether a handler has been defined for
> the requested resource's pipeline, that is able to handle this specific
> error. If such a handler does not exist, a handler responsible for the whole
> subsitemap is searched. If it also does not exists, an over-all default
> handler, defined in the root sitemap, would be used.
> Our idea now is to extend the tag <map:pipelines> for being able to contain
> <map:handle-errors> tags and add the above behaviour to the treeprocessor.
> This allows handler's to be defined for the hierarchy levels subsitemap and
> sitemap:
> Sitemap:
> <map:pipelines>
> <map:pipeline>
> <map:mount src=”subsitemap”/>
> </map:pipeline>
> ...
> <map:handle-errors> <!-- default handler for whole system -->
> ...
> </map:handle-errors>
> </map:pipelines>
> Subsitemap:
> <map:pipelines>
> <map:pipeline>
> ...
> <map:handle-errors> <!-- handler for pipeline -->
> ...
> </map:handle-errors>
> </map:pipeline>
> ...
> <map:handle-errors> <!-- handler for whole subsitemap -->
> ...
> </map:handle-errors>
> </map:pipelines>
Oh, I love it!
> 2) Each error handler shall not only regard the type of the occured
> exception for the decision, whether he is responsible for it, but further
> properties like error codes etc., that are accessible via bean-style methods
> in the exception object.
> Our idea for this is to extend the new
> org.apache.cocoon.selection.ExceptionSelector, so that an error handler
> definition could look like:
> <map:selector name="exception"
> src="org.apache.cocoon.selection.ExceptionSelector">
> <exception name=”myexc1” class=”example.MyException1”/>
> <exception name=”myexc2” class=”example.MyException2”/>
> </map:selector>
> ...
> <map:pipeline>
> ...
> <map:handle-errors>
> <map:select type=”exception”>
> <map:when test=”type=myexc1,errorCode=10”>
> ...
> </map:when>
> <map:when test=”type=myexc2,errorCode=20”>
> ...
> </map:when>
> </map:select>
> </map:handle-errors>
> </map:pipeline>
> In this case the exception classes example.MyException1 and
> example.MyException2 are expected to have a method getErrorCode() which is
> called via reflection from within the selector.
> One could also think about allowing more complex expression within the test
> attribute like (type=myexc1 and errorCode>=10 and errorCode<20) etc.
>
> Any comments?
I see great value on better error handling capabilities and the approach
is clean and well back compatible.
+1
--
Stefano.
Re: Extending error handling
Posted by Björn Lütkemeier <bl...@s-und-n.de>.
Hi,
> -----Ursprüngliche Nachricht-----
> Von: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Gesendet: Montag, 7. April 2003 11:17
> An: cocoon-dev@xml.apache.org
> Betreff: Re: Extending error handling
>
>
> Björn Lütkemeier wrote:
>
> >Hi,
> >
> >for a customer we need two extensions to the current error handling in
> >Cocoon. Since we think, that this extensions may be of general
> interest in
> >Cocoon, we'd like to ask what you think about it? Thanks for answers!
> >
<snip/>
>
> >2) Each error handler shall not only regard the type of the occured
> >exception for the decision, whether he is responsible for it, but further
> >properties like error codes etc., that are accessible via
> bean-style methods
> >in the exception object.
> >Our idea for this is to extend the new
> >org.apache.cocoon.selection.ExceptionSelector, so that an error handler
> >definition could look like:
> ><map:selector name="exception"
> >src="org.apache.cocoon.selection.ExceptionSelector">
> > <exception name=”myexc1” class=”example.MyException1”/>
> > <exception name=”myexc2” class=”example.MyException2”/>
> ></map:selector>
> >...
> ><map:pipeline>
> > ...
> > <map:handle-errors>
> > <map:select type=”exception”>
> > <map:when test=”type=myexc1,errorCode=10”>
> > ...
> > </map:when>
> > <map:when test=”type=myexc2,errorCode=20”>
> > ...
> > </map:when>
> > </map:select>
> > </map:handle-errors>
> ></map:pipeline>
> >In this case the exception classes example.MyException1 and
> >example.MyException2 are expected to have a method
> getErrorCode() which is
> >called via reflection from within the selector.
> >One could also think about allowing more complex expression
> within the test
> >attribute like (type=myexc1 and errorCode>=10 and errorCode<20) etc.
> >
>
> In the above, the "errorCode" is actually what defines the kind of
> error. So instead of writing this in the <map:when>, it would be better
> for it to be written in the configuration of the ExceptionSelector.
>
> We could have a JXPathExceptionSelector which extends Exception selector
> to allow an XPath expression on each <exception> configuration :
> <map:selector name="exception">
> <exception name="type1" class="example.MyException1"
> test="errorCode = 10"/>
> <exception name="type2" class="example.MyException1" test="errorCode =
> 10 and contains(errorMsg, 'bad user')"/>
> </map:selector>
>
> Thoughts ?
Good idea. Actually you are right, that the errorCode and perhaps further
conditions define the kind of error and therefore could be written in the
configuration. I think such a solution is suitable for our and other user's
needs. Still have to discuss it with the customer ;-)
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
Björn
Re: Extending error handling
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Björn Lütkemeier wrote:
>Hi,
>
>for a customer we need two extensions to the current error handling in
>Cocoon. Since we think, that this extensions may be of general interest in
>Cocoon, we'd like to ask what you think about it? Thanks for answers!
>
>1) Possibility to define a "hierarchy" of error handlers: pipeline -
>subsitemap - sitemap. The behaviour is expected to be the following: When an
>exception occurs, Cocoon shall check whether a handler has been defined for
>the requested resource's pipeline, that is able to handle this specific
>error. If such a handler does not exist, a handler responsible for the whole
>subsitemap is searched. If it also does not exists, an over-all default
>handler, defined in the root sitemap, would be used.
>Our idea now is to extend the tag <map:pipelines> for being able to contain
><map:handle-errors> tags and add the above behaviour to the treeprocessor.
>This allows handler's to be defined for the hierarchy levels subsitemap and
>sitemap:
>Sitemap:
><map:pipelines>
> <map:pipeline>
> <map:mount src=”subsitemap”/>
> </map:pipeline>
> ...
> <map:handle-errors> <!-- default handler for whole system -->
> ...
> </map:handle-errors>
></map:pipelines>
>Subsitemap:
><map:pipelines>
> <map:pipeline>
> ...
> <map:handle-errors> <!-- handler for pipeline -->
> ...
> </map:handle-errors>
> </map:pipeline>
> ...
> <map:handle-errors> <!-- handler for whole subsitemap -->
> ...
> </map:handle-errors>
></map:pipelines>
>
<handler-errors> already are hierarchical. The new feature above is the
global <handle-errors>, which looks good to me. What do others think ?
>2) Each error handler shall not only regard the type of the occured
>exception for the decision, whether he is responsible for it, but further
>properties like error codes etc., that are accessible via bean-style methods
>in the exception object.
>Our idea for this is to extend the new
>org.apache.cocoon.selection.ExceptionSelector, so that an error handler
>definition could look like:
><map:selector name="exception"
>src="org.apache.cocoon.selection.ExceptionSelector">
> <exception name=”myexc1” class=”example.MyException1”/>
> <exception name=”myexc2” class=”example.MyException2”/>
></map:selector>
>...
><map:pipeline>
> ...
> <map:handle-errors>
> <map:select type=”exception”>
> <map:when test=”type=myexc1,errorCode=10”>
> ...
> </map:when>
> <map:when test=”type=myexc2,errorCode=20”>
> ...
> </map:when>
> </map:select>
> </map:handle-errors>
></map:pipeline>
>In this case the exception classes example.MyException1 and
>example.MyException2 are expected to have a method getErrorCode() which is
>called via reflection from within the selector.
>One could also think about allowing more complex expression within the test
>attribute like (type=myexc1 and errorCode>=10 and errorCode<20) etc.
>
In the above, the "errorCode" is actually what defines the kind of
error. So instead of writing this in the <map:when>, it would be better
for it to be written in the configuration of the ExceptionSelector.
We could have a JXPathExceptionSelector which extends Exception selector
to allow an XPath expression on each <exception> configuration :
<map:selector name="exception">
<exception name="type1" class="example.MyException1" test="errorCode = 10"/>
<exception name="type2" class="example.MyException1" test="errorCode =
10 and contains(errorMsg, 'bad user')"/>
</map:selector>
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }