Spring IoC Initialization Life-cycle
This is briefly enumerated:
1. Read and parse the Bean definitions (either as XML, JavaConfig)
2. Process BeanFactoryPostProcessors
3. Construct bean by calling its constructor
4. Call setters, dependencies injected
5. Inject the required beans as defined by the *Aware Interfaces
6. Call postProcessBeforeIntialization
7. Call the initializaion callbacks.(like InitializingBean’s afterPropertiesSet or a custom init-method)
8. Call postProcessAfterInitialization
Let’s quickly walk through what goes on in the Intiailization life-cycle.
Everything starts off by the reading in and parsing the Spring beans definitions as specified in either XML configuration or JavaConfig, At this point non of the beans are created yet, only the blueprint needed to start their creation. At this point Spring provides you an opportunity to hook into the process and modify the parsed bean definitions: the blueprints. You do this by having the logic you want executed at this phase in the postProcessBeanFactory method of the BeanFactoryPostProcessor interface. An example of such a BeanFactoryPostProcessor that comes with Spring isPropertyPlaceHolderConfigurer which is used to replace placeholders in bean definitions with actual values pulled from property files.
Implementing your own BeanFactoryPostProcessor would look thus:
After the BeanFactoryPostProcessors are called, then the beans can be instantiated. The Spring IoC does this by calling the respective constructors. Once the beans are constructed the next thing that would be done is calling required setters and making sure the defined dependencies are injected.
Next in line would be to then inject any defined Infrastructred dependencies as defined by any of the *Aware Interfaces. For example if a bean implements ServletContextAware Interface, then the required overriden metthod is called with the ServletContext provided.
At this point in the container life-cyle, the beans are created and all in existence. It is at this point that theBeanPostProcessor‘s can kick in. The BeanPostProcessor‘s would define two methods:postProcessorBeforeInitialization and postProcessorAfterInitialization.
Here is a conflict using @Autowired with @Configuration Meaning we cannot use BeanFactoryPostProcessor @Bean with @Autowired in the @Configuration class.