avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [Proposal] Distilling common Context Attributes
Date Wed, 28 Aug 2002 07:48:44 GMT
On Wed, 2002-08-28 at 09:35, Stephen McConnell wrote:
>  >> 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.

I think what we need to do first is decide the primitive key names and
value types a container must use to provide a certain piece of
information to a component.

For example, if a container has a notion of "home directory" at the
"application level" and exposes it to components, it should do so by
providing it to components as an instance of File with the key
"avalon.application:home.dir" inside the Context passed in.

It is too early to specify the "minimum context". For example, we do
*not* specify "all containers should provide components with a
classloader in the context using key "blah"".

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

nothing or a default (more coarse or less coarse as appropriate)

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

nothing or a default (more coarse or less coarse as appropriate)

> 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 think the concepts of application and partition are generally clear
enough to be part of the specification on this level. I do agree that
the definition of both in this context (no pun intended) should be part
of the proposal.

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>


Mime
View raw message