Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 47040 invoked from network); 2 May 2007 12:44:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 May 2007 12:44:05 -0000 Received: (qmail 80169 invoked by uid 500); 2 May 2007 12:44:03 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 80090 invoked by uid 500); 2 May 2007 12:44:03 -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 List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 80071 invoked by uid 99); 2 May 2007 12:44:03 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 May 2007 05:44:03 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 May 2007 05:43:56 -0700 Received: from [192.168.0.156] (unknown [80.240.191.89]) by smtp.mxes.net (Postfix) with ESMTP id 67713519DD for ; Wed, 2 May 2007 08:43:34 -0400 (EDT) Message-ID: <4638877F.8070006@apache.org> Date: Wed, 02 May 2007 14:43:43 +0200 From: Grzegorz Kossakowski User-Agent: Thunderbird 1.5.0.8 (X11/20060911) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Why we have our own SAXParser interface? References: <46360A72.5050604@tuffmail.com> <5234B0CE-DF34-482B-922B-0A066A0B9531@apache.org> <46366395.2060302@apache.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Carsten Ziegeler napisał(a): > Yes, I think so - at least for new code we should use the new interfaces. > Actually I forgot the main reason for the new stuff :) The Avalon > version is pooled which does not fit nicely into the bean approach (and > Spring); we have supported for pooling Avalon components, but obviously > pooling is not the best solution. The new stuff does not require pooling > anymore. > I see. Thanks for explanation! -- Grzegorz Kossakowski