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

digital products for a global economy

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

View raw message