> -----Ursprüngliche Nachricht-----
> Von: Gerhard Froehlich [mailto:[EMAIL PROTECTED]]
> Gesendet: Sonntag, 12. August 2001 13:04
> An: cocoon
> Betreff: [c2 todo] handle error inside pipeline
>
>
> Hi Team,
> following todo in the pipeline:
> -->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
> -->configurable intermediate output stream.
>
> Let me try to retrace this problem:
> A pipeline serializes for example a xml to pdf with fop. Now fop starts to
> serialize the
> xml to pfd. In the middle of the processing fop throws an
> exception, because
> the xsl
> stylesheet is buggy. But a part of the document is already serialized and
> because of that
> the acrobat reader opens and displays a corrupt pdf document.
> Know you want something between the final output stream which handles this
> errors, and throws
> for example a ProcessingException.
>
> Do I have the point if the problem?
>
Yes, this is exactly the problem. If you use any other serializer, e.g.
html,
and an exception occurs in the middle of the processing, the response
contains
the "first correct part" of the html, the exception triggers the
<map:handle-errors>
"pipeline", the ErrorNotifier creates SAX events for the exception and these
SAX events are handled by <map:handle-errors> "pipeline", e.g. by using a
stylesheet
to transform this to html.
Now the whole response consists of the "first correct part in html" and the
exception in html, which is quiet a mess on the client.
If you use PDF (or the FOPSerializer) an intermediate output stream is
already created
which should avoid the scenario you described above.
We had several weeks ago a discussion on this topic. I think the most other
developers
(excluding me) favored the "configurable per pipeline" approach, which means
the
sitemap editor has to take care, which pipelines should use this
intermediate output
stream and which not (default is not). This decission was made because of
possible
performance lost if the intermediate output stream was used everywhere.
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: [EMAIL PROTECTED]
================================================================
> Cheers
> Gerhard
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
