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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]] > >> > >> At 7:59 am -0500 19/3/02, Vadim Gritsenko wrote: > >> >> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > >> >> > >> >> From: "Jeremy Quinn" <[EMAIL PROTECTED]> > >> >> > >> >> > 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:[EMAIL PROTECTED]> <http://www.media.demon.co.uk> > <phone:+44.[0].20.7737.6831> <pager:[EMAIL PROTECTED]> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
