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: [RT] Cocoon component container and excalibur
Date: Thu, 3 Jun 2004 08:40:17 +0200
Organization: S&N AG
MIME-Version: 1.0
Thread-Index: AcRJMpryyq0VcgqxQu2Z0h2nhtiCZwAAoWAQ
In-Reply-To: <40BEC4AD.8010802@apache.org>
Message-ID: <OF705D456A.890D717C-ONC1256EA8.0023DAAF@sundn.de>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

Sylvain Wallez wrote:
> 
> You have to consider two very different things:
> - the Avalon framework APIs (LogEnabled, Serviceable, 
> Configurable, etc.)
> - the container that implements the framework behaviour
> 
> Although the container implementation may change, there's a 
> strong commitment to the framework APIs as this is what we've 
> used and invested in for many years.
> 
> So even if a new container comes with new features (e.g. IOC 
> type 2/3), it will also have to implement the Avalon 
> framework behaviour. We cannot trash years of use of this API 
> overnight.
> 
I don't want to freak out again but if you look at the discussions
about the block implementations, there were a lot of discussions
to also remove the framework api from the block system. So if you
want to use the benefit of blocks, you can't use the avalon
framework api for your components. And I still think this is bad.

Anyways, if for example we would move to Fortress (without using
the meta-info stuff and keeping our current configuration files
which is possible!) we could add own lifecycle interfaces over
time and provide a smooth migration path to whatever comes with
blocks.

Carsten