polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "zhuangmz08" <zhuangm...@qq.com>
Subject 回复: service initialization order?
Date Tue, 19 Apr 2016 14:11:48 GMT
Thank you so much.
Yes, I'm Chinese living in Shenzhen about 1000km away from Shanghai. I'm surprised that you
live in China too. Yes, I think we can meet up someday this year:)
I love zest so much!




------------------ 原始邮件 ------------------
发件人: "Niclas Hedhman";<hedhman@gmail.com>;
发送时间: 2016年4月19日(星期二) 晚上9:36
收件人: "dev"<dev@zest.apache.org>; 

主题: Re: service initialization order?



1. Yes dependency trees are effectively in place. In reality is somewhat
simpler... A model is built from all registered types and what injection is
required for each. When the service is referenced, and it hasn't been
activated, it is activated.
That means if serviceA has serviceB injected, when the serviceA is
activated, the serviceB will be activated if needed. That is pretty
obvious. But if both serviceA and serviceB is marked instantiate on
startup, you will not be guaranteed that serviceB will be activated first,
just because serviceA depends on it.
I don't think you can influence this, other than create a third service
that calls them in order

2. Yes

3. I need Paul to answer that. I am not sure.

BTW, I guess you are Chinese. Do you live in China? In Shanghai? If you
want, we can meet up...

Niclas
On Apr 19, 2016 09:03, "zhuangmz08" <zhuangmz08@qq.com> wrote:

> Hi,
>
>
> I'd like to ask the following 3 questions, any help will be appreciated.
> 1.  What's the extract order when multiple service activate? Does it
> starts up along the dependency tree? Can I specific the order?
> 2.  Does they passive one by one in the reverse order?
> 3.  Could you explain more details on the life cycle of a service?
>   beforeConstructor -> constructor -> postConstructor -> beforeActivation
> -> activate -> postActivation -> beforePassivation -> passavate ->
> afterPassivation?
> Thanks a lot.
Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message