cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <>
Subject Re: Modularized Spring Modules
Date Thu, 24 Oct 2013 21:00:52 GMT
Let me clarify some terms first, this might be confusing.  There is
instantiation and then there is initialization.  Instantiation is
calling the constructor.  Initialization is calling the
@PostConstruct.  Beyond that there is what I've been calling
"CloudStack Extended Lifecycle,"  This for bean implementing
ComponentLifecycle or an extensible interface, like DataStoreProvider.
 Since I'm not sure which aspect your asking about, I'll just explain
the whole process.

Spring is now arranged into a hierarchy of contexts.  The parent
contexts are initialized first, and then the children afterwards.  So
the process goes as follows

1. Instantiate all beans in the current context - There is no way to
deterministically control the instantiation of beans within a context.
 This is just a fundamental fact that can't change.  So beans are
randomly instantiated.
2. Inject all dependencies on all beans in current context - This
entails injecting all the dependencies defined by @Inject.  The order
is not really deterministic which beans get injected first.
3. Initialize all beans in graph order - This entails calling all
methods that have @PostConstruct.  Once the beans are all wired up
they form a graph of dependencies.  Child beans are initialized first,
then the parent.  CloudStack has a lot of circular dependencies in the
beans currently, so while this is intended to be deterministic, you
may find issues.  The storage code is particularly bad in this area,
but if you are defining your beans in your own context then this
doesn't apply.  Only if you add beans to the "core" context will you
find issues.  If a class has an initialization dependency that is not
express through its bean dependencies, you can add "depends-on" to the
bean defintion in the XML.  This will ensure that the specified bean
will be initialized first.
4. CloudStack Extended LifeCycle: Call ComponentLifecycle.configure()
on all ComponentLifecycle implementing beans
5. CloudStack Extended LifeCycle: Register extensible types.  This
phase happens really at the same time as step 4.  When an extensible
type is registered nothing typically happens except that its stored in
a list.  Storage is different in that when the DataStoreProvider is
registered, at that time DataStoreProvider.configure() will be called.
 Notice that even though DataStoreProvider.configure() has the same
signature as ComponentLifecycle.configure() it is different.  Honestly
with the new Spring code we can remove DataStoreProvider completely,
but that's a different discussion

After the context is initialized following the steps above, it will
then initialize all the child contexts.  Once all contexts have been
completely initialized, ComponentLifecycle.start() will be call on all
beans starting with the parent context, then children.

A general guide line of when to use ComponentLifecycle.start() vs
@PostConstruct is if your initialization logic starts a background
thread or requires all extensible types to be registered, then you
should use ComponentLifecycle.start().  All other initialization code
should be in @PostConstruct.  ComponentLifecycle.configure() is
largely useless in my mind and should be avoided.

I hope somewhere in all that is something that answered your question.
 If not you can email me directly with your spring config and I can
help, or we can setup a GTM.


On Thu, Oct 24, 2013 at 1:04 PM, SuichII, Christopher
<> wrote:
> Darren,
> I’m switching my plugin over to use the new modularized Spring stuff you just merged
and there is something I’m still battling with. I have other beans that were previously
instantiated before my DataStoreProvider which get injected into the provider, lifecycle,
etc. So, those beans need to be instantiated before the DataStoreProvider. How can I ensure
those beans are created and setup before the DataStoreProvider does?
> -Chris
> --
> Chris Suich
> NetApp Software Engineer
> Data Center Platforms – Cloud Solutions
> Citrix, Cisco & Red Hat

View raw message