Spring Life Cycle

First of all Thank you to Frank P Moley(https://www.lynda.com/Frank-P-Moley/) for his explanation on Spring Life cycle. I am trying to document the information for my reference and whosoever it helps

Spring Life Cycle - has following 3 phases
  1)Initialization
  2)Use phase
  3)Destruction phase

There are three distinct phases of a Spring lifecycle. The first is the initialization phase. Most of the work that we do within the Spring framework, through the configuration of the application context directly impacts the initialization phase.

The use phase is actually the single largest point at which your application spends within the lifecycle itself. For a typical application, over 99% of its time is actually in the use phase of the Spring lifecycle. It really is a very simple case of IOC. The destruction phase called when u invoke close on the application context.

Initialization Phase :

  - Begins with creation of Application Context
   -BeanFactory initialization phase
   -Bean initialization and instatiation

The initialization phase of a Spring Bean application's lifecycle begins with the creation of the ApplicationContext.When you're running a web application the ApplicationContext is actually started as part of the Servelet initialization phase itself. The Servelet calls in and starts the ApplicationContext and indeed the ServeletContext is what actually has the handle to the ApplicationContext. The first part of the initialization phase, after the ApplicationContext starts is the BeanFactory initialization phase.

But know that the ApplicationContext, again, is the wrapper for the BeanFactory, but the BeanFactory itself has to be brought up correctly. And that is done during the BeanFactory initialization phase of the Spring Bean lifecycle. After the BeanFactory is primed and ready to run we'll get into individual bean initialization and instantiation operations. There's all kinds of places here that we can impact the behavior of an individual bean and during the initialization phase most if not all of those are set.

The first thing that happens, is as I mentioned, the BeanFactory is loaded. And that BeanFactory initialization occurs in two distinct points.

The bean definitions themselves are loaded into the BeanFactory through their metadata and then there's a process by which we actually do post-processing on the bean definitions themselves, called BeanFactory post-processing. Once the BeanFactory itself is initialized and ready to be used, then we iterate through all of the beans in that factory and go through a process that occurs on each individual bean. Each bean is instantiated, set with appropriate setters, bean post-processors are then executed that happen before the initializer.

The initializer itself occurs. And then bean post-processors that happen after the initializer.  But once this whole lifecycle is executed and ready to run, we then proceed into the use phase of our application.

Initialization phase again divided as follows

1) Loading Bean definitions: 

•  The bean definitionas are loaded into the BeanFactory from  all sources i.e. Java configuration, XMl configuration and Component scanning and autoconfiguration.
•  Id is used to create the index for the bean in the bean factory.
•  Bean factory at this point only contains reference and no class has been created yet.

2)Init : Post-Process Bean Definitions/ Bean Factory Post - Processors

    - Perform work on the entire BeanFactory

    - Can modify or transform any bean in the factory prior to instantiation

    - Most familar example is the "ProprtySourcesPlaceholderConfigurer" :-  

      The PropertySourcesPlaceholderConfigurer takes property files, parces   them, and injects the     property  values into the bean before it's ever instantiated

 3)Bean Instantiation

   - Beans are instantiated in the factory using constructors.

   - Done in the correct order to ensure dependencies are created first.

   - Handle to class instance remains in the bean factory for the lifecycle  of the application for singletons

   - By default, all beans are instatiated eagerly

   - In order for a bean to be lazily instantiated, it not only needs to be annotated as lazy, but it also has to have nothing else in the bean  factory that uses them as a dependency. If a bean is a dependency of      another bean, it cannot be lazily instantiated.

   - Lazy beans can be specified as lazy, but ApplicationContext reserves the  right to ignore

   - When this phase is completed, Bean pointer is still referenced in  Beanfactory and Objects have been constructed but they are not available  for use yet.

4)Setters

 - Once all of the beans have been instantiated and all of the required dependencies injected with those constructor-level injections, we now have fully qualified classes ready to be used. However, Spring then goes through each of those classes and modifies them through the setter argument.

- Setters are called

- Autowiring occures(non constructor based).

- Once this phase completes, beans are fully initialized and all the dependencies are injected but beans still not ready for use.

5)Bean Post-Processing

  - Final point of configuration manipulation

  - Each bean may have additional behaviors added

  - Two types of extensible and generic processing : before and after initializer

  - The methods annotated with @PostConstruct methods called here

  - There also is a BeanPostProcess Interface and this interface allows you to inject common behavior into a specific bean or a class of beans. Now, it's important to note that, even if you're dealing with a class of beans, you're still operating on each bean individually. There are two types of methods that you can have before initializer and after initializer, also known as pre-init and post-init methods. The framework itself also leverages a lot of these BeanPostProcessors.

- There also is a BeanPostProcess Interface and this interface allows you to inject common behavior into a specific bean or a class of beans. Now, it's important to note that, even if you're dealing with a class of beans, you're still operating on each bean individually. There are two types of methods that you can have before initializer and after initializer, also known as pre-init and post-init methods. The framework itself also leverages a lot of these BeanPostProcessors.

-When this phase is complete, you will have beans that are fully instantiated and initialized. All of the dependencies will be injected and all behavior will be added to each and every bean. At this point, all of our beans are actually ready to use.

The Initialization phase : Differences based on configuration types

 

  Java Configuration

   - Instantiation and setters are merged

   - Each method with @Bean annotation is executed in proper order

  

  AutoConfiguration

   - Instantiation of all beans scanned

   - @Autowired constructors

   - Then during setter injection, Autowired setters anf fields

    

  XML Configuration

    - Instatiation of all beans and constructor arg injection

    - Property injection

Use Phase

 - Most of the time is spend in this phase

 - ApplicationContext serves proxies to the original class

 - ApplicationContext maintains handle to each bean(Singleton)

 - Spring provides interface ApplicationContextAware - gives your class a handle to the ApplicationContext and this is not a very common interface to use, but is available during the use phase

Destruction Phase

 -The destruction phase in a Spring application begins when close is called on the application context. Now, this can either be a manual call to close or when the framework in which the application itself is running calls close. As the application context itself is starting to close, any method that is annotated with @PreDestroy or the corresponding XML notation for a PreDestroy method, that method itself is executed at that point.

 - Beans are not destroyed at this point. An important thing to note is that the beans themselves are not destroyed at this point. In a Java world, the only thing that can destroy a class itself is the garbage collector so calling close on the application context makes every bean contained within it go out of scope and allow it to be garbage collected during the normal processing.

When close is called, the application context goes out of scope and all handles to it are released. Prototype beans are not impacted by the destruction phase either. Because a prototype bean no longer is handled by the application context once it's constructed, they go out of scope immediately when the application class itself no longer needs them. And as I previously mentioned, garbage collection is the only thing that can destroy an instance of a bean.