Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 63873 invoked from network); 28 Aug 2002 17:12:47 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 28 Aug 2002 17:12:47 -0000 Received: (qmail 14143 invoked by uid 97); 28 Aug 2002 17:12:57 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 13999 invoked by uid 97); 28 Aug 2002 17:12:55 -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 13945 invoked by uid 98); 28 Aug 2002 17:12:54 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Reply-To: From: "Berin Loritsch" To: "'Avalon Developers List'" Subject: RE: [Proposal] Distilling common Context Attributes Date: Wed, 28 Aug 2002 13:12:14 -0400 Message-ID: <005501c24eb6$0e610950$ac00a8c0@Gabriel> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <1030520431.1461.30.camel@lsd.bdv51> Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Keep in mind that the proposal is referring to a minimum basic set that all containers need to supply. Anything more than that basic set is specific to that container. > -----Original Message----- > From: Leo Simons [mailto:leosimons@apache.org] > Sent: Wednesday, August 28, 2002 3:41 AM > To: Avalon Developers List > Subject: Re: [Proposal] Distilling common Context Attributes > > > On Wed, 2002-08-28 at 08:55, Stephen McConnell wrote: > > > > Less is more. > > > > In the list below I don't see why we need component, partition and > > application seperation - these notions are container specific. > > I disagree. Where some containers may not provide this > separation (and hence only support the "component" space), > those that do provide a separation should provide the same one. > > > I would prefer to the subset : > > > > avalon:home.dir > > avalon.work.dir > > avalon::common.classloader <-- but question on this > > avalon::name > > > > I've included the avalon:name entry because without it you > will not be > > able to resolve all of the Phoenix portability issues. > > Before accepting this as a common part of the framework, I > think a definition of what avalon:name contains (type, > contract) is neccessary, as well as a rationale different > than ("phoenix portability issue") is needed (ie like Berin > did for the other attrs). Can we start with the proposed > three and add this one later? > > > For the home and > > work values - no problem - for the "common.classloader" - > what does this > > mean - is it different from a regular classloader supplied to the > > component ? > > to me "common" implies "shared"... indicating that the > component must accept the fact that it may share its > classloader with other components. The scoping issue pete > mentions wrt to the directory setup does not apply > (classloaders themselves already cascade). Hence, a different > namespace from "component|partition|application" must be used > and common is a natural choice. > > my thoughts only, of course =) > > However, due to reasons mentioned previously, I still think > the namespace base should be "avalon". I'm not going to -1 > based on that though... > > cheers, > > Leo > > > > -- > To unsubscribe, e-mail: > unsubscribe@jakarta.apache.org> > For > additional commands, > e-mail: > -- To unsubscribe, e-mail: For additional commands, e-mail: