Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E95717C.3070400@anyware-tech.com>
Date: Thu, 10 Apr 2003 15:28:28 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Errorhandling for internal requests
References: <OFB7D3F518.8E9F19B4-ONC1256D04.003B1B25@rz-c007-j650.basf-ag.de>
In-Reply-To: <OFB7D3F518.8E9F19B4-ONC1256D04.003B1B25@rz-c007-j650.basf-ag.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

juergen.seitz@basf-it-services.com wrote:

>Hi Sylvain,
>
>our problem was, that not the error handler itself should decide if it is
>responsible for external, internal or always,
>but the caller of the resource must do it.
>In our opinion the distinction only makes sense for redirects and for
>example not for generators (Please see our examples)
>  
>

What's the difference between
  <map:redirect-to uri="cocoon://blah">
and
  <map:generate src="cocoon://blah">
  <map:serialize/>

Not that much, in fact... I don't think your use case can be considered 
as a general behaviour that should be "hardcoded" in the sitemap engine.

If we need to tell externally to the called pipeline if it should handle 
errors or not, this should go through the URI. We can either use a 
particular subprotocol (e.g. "cocoon:handle-errors://blah"), or an 
additional request parameter (e.g. 
"cocoon://blah?cocoon-handle-errors=false"). I like the second solution 
more, but we must take great care that this parameter is allowed only 
internally to avoid any security hole.

But I'm still not sure it's good to control error-handling behaviour 
from the oustide. At least we must have it from the inside.

What do others think ?

Sylvain

>juergen.seitz@basf-it-services.com wrote:
>  
>
>>Hi,
>>
>>we noticed the following fact concerning the treeprocessor: In case of an
>>internal request, the error handler defined for a pipeline is explicitly
>>NOT called to handle an exception, but the exception is simply thrown. Now
>>lets consider two scenarios:
>>
>>1)
>><map:pipeline>
>>            <map:match pattern="test1">
>>                        ...
>>            </map:match>
>>            <map:handle-errors> <!-- handler 1 -->
>>                        <map:select type="exception">...</map:select>
>>            </map:handle-errors>
>></map:pipeline>
>><map:pipeline>
>>            <map:match pattern="test2">
>>                        <map:generate src="cocoon://test1"/>
>>                        ...
>>            </map:match>
>>            <map:handle-errors> <!-- handler 2 -->
>>                        <map:select type="exception">...</map:select>
>>            </map:handle-errors>
>></map:pipeline>
>>In this case it is of cause reasonable NOT to call handler 1 if test1 causes an exception, since otherwise the generator would not notice, that an exception has occurred in test2. In fact it would receive data produced by handler 1, which it may not be able to process. Therefore in the current implementation resource test1 throws an exception to the generator, that is then handled by handler 2. So this case is ok, nothing to do :-)
>>
>>2)
>><map:pipeline>
>>            <map:match pattern="test1">
>>                        ...
>>            </map:match>
>>            <map:handle-errors> <!-- handler 1 -->
>>                        <map:select type="exception">...</map:select>
>>            </map:handle-errors>
>></map:pipeline>
>><map:pipeline>
>>            <map:match pattern="test2">
>>                        <map:redirect-to uri="cocoon://test1"/>
>>            </map:match>
>>            <map:handle-errors> <!-- handler 2 -->
>>                        <map:select type="exception">...</map:select>
>>            </map:handle-errors>
>></map:pipeline>
>>In this case however it may be completely unsuitable, that handler 1 is not called. In our opinion by performing the redirect test2 is no longer responsible for what happens. If an error occurs in test1 handler 1, who knows what to do then, should handle it. Handler 2, which is called in the current implementation, would normally not know anything about the specific exceptions, that may occur in test1.
>>
>>To solve this problem we propose to add a new boolean attribute "handle-errors" to the <redirect-to>-tag. If it is set to "true", the treeprocessor calls the resource's error handler if an exception occurs, if it is set to "false", the exception is thrown like today. To ensure complete backward compatibility the default will be "false".
>>
>>Any comments?
>>
>>    
>>
>
>I had some thoughts about this while refactoring error handling, and my feeling is that what this flag should be better located on the <map:error-handler>, since this is where you know if the pipeline should provide an error page in case of failure (case of coplets for example) or propagate the exception.
>
>This would then become <map:handle-errors when="always">, with possible values for "when" being "external", "internal", "always". The default being "external", since it is the current behaviour.
>
>Thoughts ?
>
>Sylvain
>  
>
-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }