avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [ISSUE] containerkit
Date Tue, 02 Jul 2002 18:31:31 GMT

Leo Sutic wrote:

>>From: Stephen McConnell [mailto:mcconnell@osm.net] 
>>Ok - I missundestood - your making a distinction concerning 
>>the source 
>>of context value resolution.
>>I am I correct in assuming that what your describing is the 
>>need/interest in declaring to a container that it is responsible for 
>>supplying a context value (as destinct from the case of an assembly 
>>defining the context value) ?

Ok - I'm moving into "thinking-out-loud-mode".

Two approaches:

   (a) static approach

         The static approach assumes that ALL containers will
         provide support for "well-known" context values -
         e.g. "avalon.work.dir", "avalon.home.dir", etc.
         (Similar to java.lang.System.getProperties() approach).

         This can be easily addressed by the container creating
         the root contxt object and passing this to a child
         context.  The root context contains the container
         generated values and the child context contains the
         assembler defined values (this is currently supported
         functionality in ContextFactory).

         This would not require and declarative additions to a
         context declaration because the values are always
         supplied by any container.

   (b) dynamic approach

         Whould require enhancement of the entry descriptor
         to declare that a context value is sourced from the
         container and not from the criteria.

             <entry key="my-root-dir-key"
           <!-- other assembly based directives go here -->

         The intention of the <import/> fragment is to declare
         the requirement by a container to add a object into the
         context hierachy under the key "my-root-dir-key" and that
         the object to enter under the key is whatever the container
         documents as the value of the named resource.

         This would enable components to declare depedencies on
         container specific resources which would allow validation
         prior to instantiation.

Cheers, Steve.

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


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