Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <dev@cocoon.apache.org>
Subject: RE: error handling
Date: Tue, 8 Jun 2004 14:25:15 +0200
Organization: S&N AG
MIME-Version: 1.0
Thread-Index: AcRNSxyLYsrHHBeES+yVeYA8lsuNNwACAJUQ
In-Reply-To: <40C5A30D.1070205@vafer.org>
Message-ID: <OFCC217546.2EFD38EF-ONC1256EAD.00436A55@sundn.de>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

Torsten Curdt wrote:
> 
> Ok, but isn't the "cocoon:" source going back to 
> treeprocessor after all? Or does it just setup the pipelines? 
> I thought every request is goint through the TP.
> 
The cocoon: protocol is going through the TP for setting up the
pipeline. The assembled pipeline component is returned to the
protocol (Source) and from there directly invoked. So during
execution of the pipeline the TP is not involved at all.

> 
> > So we can add add handle-errors="always|external|internal" and 
> > "?cocoon:handle-errors=true", but it will handle errors occuring 
> > during the _building_ of the pipeline, and not during its 
> _execution_.
> 
> That's not what I am after. It does not help for error 
> handling on aggregation. We should aim for the execution time.
> 
Yepp, execution time is imho more important - if we can do both, great :)

> 
> I'd propose to change what needs to be changed.
> 
Yes :)

I think, Sylvain outlined here

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107876029119774&w=2

what has to be done. It should be fairly easy to add this to control
the error handling at execution time. Controlling the error handling
on construction time is very easy as well.

If we add this to 2.2-dev we can change things anyway (even interfaces
if required).

Carsten