Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 74459 invoked from network); 6 Jun 2002 13:39:44 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 6 Jun 2002 13:39:44 -0000 Received: (qmail 11055 invoked by uid 97); 6 Jun 2002 13:39:44 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 11010 invoked by uid 97); 6 Jun 2002 13:39:43 -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 10998 invoked by uid 98); 6 Jun 2002 13:39:43 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Reply-To: From: "Berin Loritsch" To: "'Avalon Developers List'" Subject: RE: ContainerManager and Sub-containers Date: Thu, 6 Jun 2002 09:39:24 -0400 Message-ID: <002801c20d5f$924784d0$ac00a8c0@Gabriel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CFF4754.1000009@osm.net> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > From: Stephen McConnell [mailto:mcconnell@osm.net]=20 >=20 > Leo Sutic wrote: >=20 > >>From: Peter Donald [mailto:peter@apache.org] > >> > >>Lets see - I can think of two reasons ;) > >> =20 > >> > > > >One reason will be enough - as long as it has to do with=20 > scalability,=20 > >which was what you claimed was the problem. ;) > > > >Your first reason is a design decision - does a component manager=20 > >manage resources, or is it a directory lookup? I go for the=20 > former, you=20 > >go for the latter. The nice thing about Avalon, IMO, is that=20 > it isn't=20 > >just a naming lookup - I have JNDI for that. > > >=20 > I look at the resulting divergence - you have the "release" operation=20 > which is only applicable in the case of pooled resources and yet the=20 > semantics of a pool are undefined at that level or abstraction. The=20 > default implementation of release in CM and SM are empty -=20 > perhaps this=20 > suggests something - its an operation that is inconsitent with the=20 > abstraction supported by CM/SM. Would it not be more appropriate for=20 > "release" to be moved up to another interface where the concepts of a=20 > pool is defined? =20 >=20 > But we've had this discussion before ;-). Reminder to everyone: The reason for the release() method was largely in part due to the design decisions of the Pool mechanism at the time. -- To unsubscribe, e-mail: For additional commands, e-mail: