You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Anton Tagunov <at...@mail.cnt.ru> on 2003/06/13 10:09:21 UTC
[Conceptual] [Fortress] component startup order
Hello, Berin, Leif and All_the_interested! :-)
* component startup order (derived from the dependency graph)
currently has an interesting interference with
* activation policy
In fact, all the components are first sorted topologically,
and then this sorted list is randomly torn into 3 parts:
inline, backbground and lazy activation policies.
In fact if we have dependency
A - > B
but A has inline activation and B - background, A will
still be (probably?) initialized before B.
Lazy initialization worries me somewhat less - I have
a feeling that the component will come up in proper time,
but it looks like if a component with inline initialization
depends on a component with background initialization it
should either be considered an error or the policy for
the offending component should be changed to inline.
Thoughts?
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Conceptual] [Fortress] component startup order
Posted by Peter Royal <pr...@apache.org>.
On Friday, June 13, 2003, at 04:09 AM, Anton Tagunov wrote:
> In fact if we have dependency
>
> A - > B
>
> but A has inline activation and B - background, A will
> still be (probably?) initialized before B.
Unless things have radically changed, doing ServiceManager.lookup(
B.ROLE ) will make sure that B is initialized before returning the
component. So A will be fine.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Conceptual] [Fortress] component startup order
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Anton Tagunov [mailto:atagunov@mail.cnt.ru]
>>
>>In fact if we have dependency
>>
>> A - > B
>>
>>but A has inline activation and B - background, A will
>>still be (probably?) initialized before B.
>
>
> Doesn't that mean that B will be initialized as a part of A's
> init, as lazy init kicks in?
Yep.
All components will fall back on lazy initialization if
for some reason it is not initialized before it is requested.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: [Conceptual] [Fortress] component startup order
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Leo!
AT> From: Anton Tagunov [mailto:atagunov@mail.cnt.ru]
AT>
AT> In fact if we have dependency
AT>
AT> A - > B
AT>
AT> but A has inline activation and B - background, A will
AT> still be (probably?) initialized before B.
LS> Doesn't that mean that B will be initialized as a part of A's
LS> init, as lazy init kicks in?
1)
Don't think so.
If I understand the code correctly then if A has activation policy
'inline' and B - 'background' then when A is initialized the
handler for B won't be prepared yet, will it?
2)
errr.. I seem to find I probably do not understand the code
sufficiently.. ThreadSafeComponentHandler does need
preparation, does not it? But then how does the lazy
initialization work at all?
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Conceptual] [Fortress] component startup order
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Anton Tagunov [mailto:atagunov@mail.cnt.ru]
>
> In fact if we have dependency
>
> A - > B
>
> but A has inline activation and B - background, A will
> still be (probably?) initialized before B.
Doesn't that mean that B will be initialized as a part of A's
init, as lazy init kicks in?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org