Peter Donald wrote:
> At 04:37 AM 6/28/2002 +0200, you wrote:
>
>>> The Component/Application Profile classes provide a basis for all
>>> the Profile information. However it is possible that some containers
>>> will extend these classes to provide specific information relevent
>>> only to the particular container. However for many containers (ie
>>> Phoenix and Fortress) the base Profile classes should be sufficient.
>>
>>
>>
>> :-)
>> Pete - are you hinting that Merlin may want more?
>
>
> Yep - so will myrmidon, most likely.
>
>>> There is significant overlap in the code for writing the container.
>>> So how do we go about sharing it all?
>>>
>>> * All containers can share the metainfo code (from containerkit)
>>> * All containers can share the lifecycle processing code (from
>>> containerkit)
>>
>>
>>
>> One problem with the lifecycle processing code. Currently the
>> codebase abstracts the processing down to startup and shutdown and a
>> per component basis. In Merlin I'm using parrallel componet
>> lifecycle processing which means that components aquire references to
>> each other before initialization, and that during the start pahse, a
>> component knows that all of its dependent service providers have
>> already been initialized. I guess all I want to do at this stage is
>> flag the potential for alternative lifecyle handlers.
>
>
> ...
>
>>> * Dependency traversal can be shared by all containers (from
>>> containerkit)
>>
>>
>> One of the things I came up with in the above parrallel processing
>> approach was the difference between a dependecy on a service
>> reference as opposed to a service usage dependecy. Service reference
>> dependecies should not restrict depedecy validation - however - using
>> the current dependecy declaration we don't have a way of saying that
>> the dependecy is only on the service reference.
>
>
> Dont get what you are saying. All providers are initialized before
> consumers aquire them and there should never be a reference to an
> object before it is good to go. So what is it you are saying exactly.
What I am saying is that there is a distinct difference between a
reference dependecy as opposed to an usage depedency. I have several
components that do not use services aquired though dependecy
declarations until some event occurs while the dependent component is
servicing client requests. In these cases the component has a
"reference" dependency - and this case enables elimination of the
recursive dependency trap - providing the container knows that the
dependent component declares that it will not use the reference until
post initialization. Given this knowlege, you can eliminate most
recusive depedency problems. As things stand - yes - we need to ensure
that the service is associated with a fully prepared component - but
that's only because we have no notion of the difference between a
reference to a dependecy as opposed to a usage depedency.
Cheers, Steve.
--
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]>
