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: error handling !*#%!
Date Wed, 20 Mar 2002 08:49:02 GMT
Vadim Gritsenko wrote:

>>From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
>>
<snip/>

>This means: Hold stream till end-of-processing. This allows: reset
>response completely, and output clean error page, without parts of XML
>previously processed.
>
>>If an internal pipeline makes an error, and has it's own
>>error-handler, I would hope that error could be inline,
>>
>
>Then the pipeline which called this internal one will never know that
>exception happened: it will get either result, or partial result and
>error (IIRC).
>

Yep : <handle-errors> isn't executed on internal request.

>Try also increasing buffer of the serializer, then environment will be
>able to reset the partial result and output clean error page. From the
>Environment:
>
<snip/>

tryResetResponse() has unfortunately nothing to do with serializer 
buffering : it is directly tied to the servlet engine's ouputstream 
buffering. This methods checks if response.isCommitted(), meaning some 
data was sent to the client, and if not, calls response.reset(), which 
empties the servlet engine's buffer.

So a solution to your problem, Jeremy, may be to increase the response 
buffer. javax.servlet.ServletResponse allows this through 
setBufferSize(), but this method doesn't exist on 
cocoon.environment.Response.

There are IMO two ways to set this value in Cocoon :
- add a new "buffer-size" parameter in web.xml : it will be then set for 
*all* requests, but having a global setting may be overkill for most request
- enhance <map:pipeline> with a "buffer-size" attribute, which allows 
fine-grained control of the buffer size at the pipeline level. This 
implies we add setBufferSize to cocoon's Request interface.

Wether we chose one or the other (or something else), I suggest to do it 
after 2.0.2.

There are also some related subjects that were left pending that could 
be discussed at that time :
- per-pipeline choice of the pipeline implementation, e.g. <map:pipeline 
type="caching">
- enhancement of <handle-errors> : having only types 404 and 500 and 
rather limiting, while a Notifying gives us an interesting "type" 
information that could be used to select a particular error handler.

Thoughts ?

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message