cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per-Olof Norén <pe...@alma.nu>
Subject Re: error handling !*#%!
Date Wed, 20 Mar 2002 12:46:00 GMT
May i suggest a look into suns multischema validation classes, which we have
used successfully in our cocoon based project.

http://www.sun.com/software/xml/developers/multischema/

/Per-Olof Norén

----- Original Message -----
From: "Jeremy Quinn" <jeremy@media.demon.co.uk>
To: <cocoon-dev@xml.apache.org>
Sent: Wednesday, March 20, 2002 12:02 PM
Subject: RE: error handling !*#%!


> At 8:44 am -0500 19/3/02, Vadim Gritsenko wrote:
> >> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
> >>
> >> At 7:59 am -0500 19/3/02, Vadim Gritsenko wrote:
> >> >> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >> >>
> >> >> From: "Jeremy Quinn" <jermq@media.demon.co.uk>
> >> >>
> >> >> > Dear All,
> >> >> >
> >> >> > I am totally mystified as to how you are supposed to
> >> >> > handle errors in
> >> >> > webapps built using Cocoon.
> >>
> >> >> If you have a better solution, please commit it, we are all
> >waiting.
> >> >
> >> >This reminds me of TODO item (in the todo.xml):
> >> >----
> >> >  <action context="code">
> >> >   Check how to handle the mixing of output streams when an error
> >inside
> >> >   a pipeline occurs. When the pipeline has something written to the
> >> >   output stream and then an error occurs the result is the first
> >> >written
> >> >   part with the appended exception.
> >> >   One solution could be a configurable intermediate output stream.
> >> >  </action>
> >> >----
> >> >
> >> >Jeremy, that's what you want, isn't it?
> >>
> >> I am not sure ..... ;)
> >
> >This means: Hold stream till end-of-processing. This allows: reset
> >response completely, and output clean error page, without parts of XML
> >previously processed.
>
> Yes it makes sense now ..... this is something that could be useful as an
> option for very specific pipelines.
>
> >
> >> 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).
>
> This is what (I think) I want, subsequent XSLT will check the response
from
> the internal pipeline and act accordingly, this is how my pipelines detect
> Validation errors from the Schematron validator, and decide not to write
> the source when an error occurs, so  this makes complete sense to me.
>
> >> not tacked on at the end of all
> >> processing, though I am obviously not understanding what is going on
> >well
> >> enough right now.
> >
> >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:
> >
> >---------
> >    /**
> >     * Reset the response if possible. This allows error handlers to
> >have
> >     * a higher chance to produce clean output if the pipeline that
> >raised
> >     * the error has already output some data.
> >     *
> >     * @return true if the response was successfully reset
> >    */
> >    boolean tryResetResponse();
> >---------
>
> Sorry Vadim, you have lost me again .....
>
>
> Thanks for your feedback
>
>
> regards Jeremy
> --
>    ___________________________________________________________________
>
>    Jeremy Quinn                                           Karma Divers
>                                                        webSpace Design
>                                             HyperMedia Research Centre
>
>    <mailto:sharkbait@mac.com>     <http://www.media.demon.co.uk>
>    <phone:+44.[0].20.7737.6831>             <pager:jermq@vizzavi.net>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.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