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:35:38 GMT

[reposted without all of the mistakes]

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 are 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 definition of an application.

   * What should a container provide in respect to a partition
     without a specification of a partition.

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

As more concrete ideas on things like "what is an application" emerge, 
we can address extensions to a common keys and attributes specification. 
  There is no need to declare them before that.

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