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. Darren On Thu, Oct 24, 2013 at 1:04 PM, SuichII, Christopher <chris.su...@netapp.com> 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 > chris.su...@netapp.com > NetApp Software Engineer > Data Center Platforms – Cloud Solutions > Citrix, Cisco & Red Hat >
