cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: handling errors in <map:aggregate> parts
Date Thu, 09 Mar 2006 18:52:46 GMT
On Thu, 2006-03-09 at 12:52 -0500, Justin Hannus wrote:
> I can't seem to get an aggregate pipeline part to respect or handle 
> errors correctly when an
> exception occurs in one of the aggregate parts. It almost seems as if 
> its impossible. This is
> whats happening...
> When an exception occurs in the a pipeline which is called as one of the 
> <map:aggregate> part elements, the erroring pipeline or parent pipelines 
> do not handle the errors correctly. In fact, the <map:handle-errors> is 
> completely ignored. What happens is the sitemap processing continues 
> even after the exception occurs and, eventually the main entry matching 
> pipeline's <handle-errors> is invoked. This is bad because when using a 
> cocoon:// request as your <map:part> src any pipelines under that 

what do you refer to with 'pipelines' here? The other map:part's?
Transformers after the map:aggregate?

> cocoon:// request will continue processing as if no error has occurred 
> but..... you will still see the cocoon error page as if processing 
> actually stopped!
> I have a pipeline which aggregates several other pipelines and then 
> writes the generated content to disk. If there is an exception in one of 
> the aggregate parts I need the sitemap processing to stop and handle the 
> exception appropriately. Instead the generated content, which has 
> errored and therefore invalid, is still written to disk. If I remove the 
> aggregate pipeline and just use a regular generator the handle-errors is 
> respected correctly and processing stops before writing the content.
> Am I misusing the <map:aggregate> elements? Or is this the expected 
> behavoir?

I have no experience with map:aggregate, but from a quick look at the
code, it doesn't catch any exceptions. What it does always do (also when
an exception occurs) is closing the root tag and sending the end
document event.

Now I'm just going to guess wildly (since you didn't mention), but if
after the map:generate you have an XSLT transformer and you write the
content using the source writing transformer, I can image the file
indeed still gets written. This is because on the one hand Xalan can
cope with the invalid input, and the endDocument event will cause it to
do the transform and thus cause the source writing transformer to do its

While the close-root-tag-and-send-end-document-event behaviour of the
aggregate is debatable, it is the nature of a SAX-pipeline that
everything in the pipeline starts executing together. Therefore things
which have side-effects and for which error recovery is important should
not be done in a streaming pipeline (therefore the source writing
transformer is considered an evil one -- don't use it).

The alternative approach is to use flowscript and its processPipelineTo
function, where you can use a try-catch block and remove the file (if
needed) when an error occurs.

Bruno Dumon                   
Outerthought - Open Source, Java & XML Competence Support Center                

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

View raw message