cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject AW: [c2 todo] handle error inside pipeline
Date Mon, 13 Aug 2001 13:10:45 GMT
> -----Urspr√ľngliche Nachricht-----
> Von: Gerhard Froehlich []
> 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.
and an exception occurs in the middle of the processing, the response
the "first correct part" of the html, the exception triggers the
"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
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
(excluding me) favored the "configurable per pipeline" approach, which means
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
performance lost if the intermediate output stream was used everywhere.


Open Source Group                        sunShine - b:Integrated
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn                          mailto:

> Cheers
> Gerhard
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message