From dev-return-62094-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Tue Jun 08 11:32:56 2004 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 44886 invoked from network); 8 Jun 2004 11:32:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 8 Jun 2004 11:32:54 -0000 Received: (qmail 16717 invoked by uid 500); 8 Jun 2004 11:32:47 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 16529 invoked by uid 500); 8 Jun 2004 11:32:45 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 16405 invoked by uid 99); 8 Jun 2004 11:32:44 -0000 Received: from [81.209.148.130] (HELO dd2020.kasserver.com) (81.209.148.130) by apache.org (qpsmtpd/0.27.1) with ESMTP; Tue, 08 Jun 2004 04:32:44 -0700 Received: from vafer.org (linux01.gwdg.de [134.76.13.21]) by dd2020.kasserver.com (Postfix) with ESMTP id 97CD588EC5 for ; Tue, 8 Jun 2004 13:26:44 +0200 (CEST) Message-ID: <40C5A30D.1070205@vafer.org> Date: Tue, 08 Jun 2004 13:29:17 +0200 From: Torsten Curdt User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: error handling References: <40C02BCD.7010104@vafer.org> <3D3265CC-B5FE-11D8-B862-000A95AF004E@apache.org> <40C08AE0.2090905@vafer.org> <40C59AB5.4080602@apache.org> In-Reply-To: <40C59AB5.4080602@apache.org> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N > Sorry to jump in late. Thanks for jumping in at all :) > There's a technical difficulty, however, as internal requests are > handled differently than external ones when it comes to handling errors > occuring during pipeline execution (not during pipeline building). > - pipelines for external requests are executed as soon as the pipeline > is ended, i.e. in the map:serialize statement, hence under control of > the treeprocessor > - pipelines for internal requests are executed when getInputStream() or > toSAX() is called on the "cocoon:" source, out of the control of the > treeprocessor. 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. ...or who is passing the request to the pipeline(s)? > 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. > Handling errors occuring during the execution of internal requests would > require some not so innocent changes in the pipeline machinery [3]. Well, IMHO this is major flaw and should be tackled. No matter if we need to change something or not. I think the pipeline machinery is so deep core that probably not to many people would notice anyway. Don't know... but maybe it would be possible to move the error handling further down to the pipeline level? If we are able to add that to the Abstract... classes even less people would be affected. But I have no clue if that's possible at all. Especially if we don't want to mix concerns. > But we can of course go one step at a time and start by catching > pipeline build-time exceptions. Not sure if that's worth the effort. I'd propose to change what needs to be changed. cheers -- Torsten