Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 18911 invoked from network); 15 Feb 2002 21:40:30 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 15 Feb 2002 21:40:30 -0000 Received: (qmail 14147 invoked by uid 97); 15 Feb 2002 21:40:33 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 14129 invoked by uid 97); 15 Feb 2002 21:40:33 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 14109 invoked from network); 15 Feb 2002 21:40:32 -0000 Message-Id: <200202152140.g1FLeVU20489@mail004.syd.optusnet.com.au> Content-Type: text/plain; charset="utf-8" From: Peter Donald To: "Avalon Developers List" Subject: Re: [VOTE] RE: ComponentManager interface Date: Sat, 16 Feb 2002 08:36:45 +1100 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: X-Wisdom-Cookie: . MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sat, 16 Feb 2002 01:30, Leo Sutic wrote: > > Correction - Excalibur has ThreadSafe, Poolable and SingleThreaded. > > Framework does not. > > I believe we went through this and found some concensus that these > three should be moved to framework as they represent general metadata > about components that all implementations of the framework should > be aware of, although they may not support those specified as optional > (Poolable, for example, should be optional). Everyone makes mistakes ;) > Wrong. Returning components or service interfaces when you are done with > them is just as fundamental as obtaining them. I disagree - that is error prone and hard to use. Much easier to automate this process and then the component writers never have to worry about it again. > It can be done with a wrapper, autogenerated by a code generator. oh god no! > And this is where I disagree - not having remove requires the client > to know about implementation details such as whether a component > is thread safe or not, whether it is pooled or not. no it doesn't. It implies that the container has to manage resource allocation and deallocation. -- Cheers, Pete ----------------------------------------------- "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -Albert Einstein ----------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: