avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [Proposal] Distilling common Context Attributes
Date Wed, 28 Aug 2002 17:12:14 GMT
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:   
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message