Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>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) ?
>>
>>
>
>Yes.
>
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.
E.g.
<context>
<import>
<entry key="my-root-dir-key"
resource="avalon.home.dir"
optional="false"/>
</import>
<!-- other assembly based directives go here -->
</context>
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.
>
>
>/LS
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
