cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Extending error handling
Date Mon, 07 Apr 2003 09:17:10 GMT
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 }



Mime
View raw message