avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [Proposal] Distilling common Context Attributes
Date Wed, 28 Aug 2002 07:27:57 GMT


Nicola Ken Barozzi wrote:

>
> 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.
>
>
> That 's what I thought, but...
>
>> I would prefer to the subset :
>>
>>    avalon:home.dir
>>    avalon.work.dir
>>    avalon::common.classloader <-- but question on this
>>    avalon::name
>
>
> The question is: how can we differentiate between component, partition 
> and application - level - stuff?
>
> What about:
>
>     avalon:home.dir
>     avalon.work.dir
>     avalon:common.classloader
>     avalon:context:name
>
> and
>
>     avalon:app.context
>     avalon:partition.context
>
> ? 


The issue is - what does it mean?
If we look at the core requirements, what we need is the primitive 
values that a container must be able to provide to a component.  But 
before doing this we must fully understand what these things mean.

The distinction between a component and an application is something that 
exists as an implementation artifact.  

  * What should containers provide in a situation where we
    don't have a formal defintion of an application.  
  * What should a container provide in respect to a partion
    without a specification of a partion.  

Putting in place specifications of the notions of application and 
partition go further the framework - as distinct from the home, work and 
classloader which are much operation aspects relative to the framework spec.

As more concrete ideas on thins like "what is an apprlication" - we can 
address extension of the common atttibutes - there is no need to declare 
them at this time.

>
>
>> I've included the avalon:name entry because without it you will not 
>> be able to resolve all of the Phoenix portability issues.  
>
>
> IIRC it has already been proposed out of a need somewhere, ok. 


It is required by several of the cornersotone components due to the 
inclusion of the getName operation in BlockContext.

>
>
>> 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 ?
>
>
> Can be.


If it is the classloader that is supplied to the component then I think 
we should drop "common" prex.

Cheers, Steve.


-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
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