From dev-return-48530-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Wed Oct 01 13:16:02 2003 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 93127 invoked from network); 1 Oct 2003 13:16:01 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 1 Oct 2003 13:16:01 -0000 Received: (qmail 23359 invoked by uid 500); 1 Oct 2003 13:15:53 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 23299 invoked by uid 500); 1 Oct 2003 13:15:53 -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 23279 invoked from network); 1 Oct 2003 13:15:53 -0000 Received: from unknown (HELO onramp.i95.net) (205.177.132.17) by daedalus.apache.org with SMTP; 1 Oct 2003 13:15:53 -0000 Received: from apache.org ([66.208.12.130]) by onramp.i95.net (8.12.10/8.12.9) with ESMTP id h91DFmk6025683 for ; Wed, 1 Oct 2003 09:15:49 -0400 Message-ID: <3F7AD388.3030805@apache.org> Date: Wed, 01 Oct 2003 09:15:52 -0400 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Disappointed about avalon usage References: <3F7A8706.3060706@Danet.de> <3F7A96CC.408@apache.org> In-Reply-To: <3F7A96CC.408@apache.org> 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 Stephen McConnell wrote: > > Michael: > > A couple of comments - the issue of the Component interface was > addressed 12-18 months ago with the introduction of the service > sub-package in the framework. The Component interface along with the > entire component sub-package is now depricated. The replacement > org.apache.avalon.framework.service makes things *much* easier and > eliminates many restrictions that exited in the past. On the other > hand, you comment concerning selectors reflect on something that > continues to bug me. I don't like selector sementics, and I think they > should be removed from the framework (in their current form), but I > don't have a migration stategy in mind. Buttom line - in my personal > opinion - selectors are a weak link in the framework container/component > contract. > > Stephen. > > (Avalon developer). Keep in mind that Fortress provides a way around the whole Selector concept, and makes things sooo much easier to manage. We also hope to add some compatibility layer of Fortress with Merlin so that you can move forward. The selector concept will eventually become obsolete like the component package--but we are still looking at the different use cases surrounding their use. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin