Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 55943 invoked from network); 3 Mar 2004 14:49:57 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 3 Mar 2004 14:49:57 -0000 Received: (qmail 61608 invoked by uid 500); 3 Mar 2004 14:49:21 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 61541 invoked by uid 500); 3 Mar 2004 14:49:20 -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 61487 invoked from network); 3 Mar 2004 14:49:19 -0000 Received: from unknown (HELO mout.perfora.net) (217.160.230.40) by daedalus.apache.org with SMTP; 3 Mar 2004 14:49:19 -0000 Received: from [217.160.230.50] (helo=smtp.perfora.net) by mout.perfora.net with esmtp (Exim 3.35 #1) id 1AyXgX-0006Rf-00 for dev@cocoon.apache.org; Wed, 03 Mar 2004 09:49:21 -0500 Received: from [208.185.179.12] (helo=reverycodes.com) by smtp.perfora.net with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1AyXgW-0002wJ-00 for dev@cocoon.apache.org; Wed, 03 Mar 2004 09:49:20 -0500 Message-ID: <4045CF35.7030504@reverycodes.com> Date: Wed, 03 Mar 2004 07:27:33 -0500 From: Vadim Gritsenko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [Portal] Why don't cocoon errors appear in a coplet ? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Carsten Ziegeler wrote: > >Olivier Billard wrote: > > >>But it's right that the portal uses the cocoon protocol to >>aggregate the various coplet contents. But why doesn't it >>detect map:handle-errors branchings ? >> >> >> >That's how the cocoon: protocol was designed :) (So, again >has nothing to do with the portal). > I think I already heard similar requests in the context of aggregator and [c|x]include transformer, so that it would be possible to execute included/aggregated pipelines without ignoring sitemap error handling. May be internal sitemap processing can be made more flexible and allow execution of handle-errors. WDYT? Vadim