The Bean life cycle interface and the entire initialization method sequence supported by Spring BeanFactory

According to the BeanFactory interface annotation of Spring 4.3.12.RELEASE version:

(The following is machine translated:)
The root interface used to access the Springbean container. This is the basic client view of the bean container; other interfaces such as ListableBeanFactory and org.springframework.beans.factory.config. A configurable BeanFactory can be used for specific purposes.

This interface is implemented by an object containing multiple bean definitions, each uniquely identified by a String name. Depending on the bean definition, the factory will return either an independent instance of the containing object (Prototype design pattern) or a single shared instance (an advanced alternative to the Singleton design pattern, where an instance is a Factory-wide Singleton). Which type of instance will be returned depends on the bean factory configuration: the API is the same. Since Spring 2.0, more scopes are available depending on the concrete application context (e.g. "request" and "session" scopes in a web environment).

The gist of this approach is that the BeanFactory is a central registry of application components and centralizes configuration of application components (eg individual objects no longer need to read properties files). See Chapters 4 and 11 of "Expert One-on-One J2EE Design and Development" for the benefits of this approach.

Note that it is generally better to rely on dependency injection ("push" configuration) to configure application objects via setters or constructors than to use any form of "pull" configuration such as BeanFactory lookup. Spring's dependency injection functionality is implemented using this BeanFactory interface and its subinterfaces.

Typically, the BeanFactory will load bean definitions stored in a configuration source (such as an XML document) and use org.springframework. beans package to configure beans. However, an implementation can simply return Java objects that it creates directly in Java code as needed. There are no restrictions on how definitions are stored: LDAP, RDBMS, XML, properties files, etc. Implementations are encouraged to support inter-bean references (dependency injection).

Unlike the methods in ListableBeanFactory, if this is a HierarchicalBeanFactor, all operations in this interface will also check the parent factory. If no bean is found in this factory instance, the immediate parent factory will be asked. Beans in this factory instance should override beans of the same name in any parent factory.

Bean factory implementations should support the standard bean lifecycle interfaces as far as possible. The full set of initialization methods and their standard sequence are as follows ( 14 steps in total ):
Bean factory implementations should support the standard bean lifecycle interfaces as far as possible. The full set of initialization methods and their standard order is:

01. BeanNameAware's setBeanName
02. BeanClassLoaderAware's setBeanClassLoader
03. BeanFactoryAware's setBeanFactory
04. EnvironmentAware's setEnvironment
05. EmbeddedValueResolverAware's setEmbeddedValueResolver
06. ResourceLoaderAware's setResourceLoader (only applicable when running in an application context)
07. ApplicationEventPublisherAware's setApplicationEventPublisher (only applicable when running in an application context)
08. MessageSourceAware's setMessageSource (only applicable when running in an application context)
09. ApplicationContextAware's setApplicationContext (only applicable when running in an application context)
10. ServletContextAware's setServletContext (only applicable when running in a web application context)
11. postProcessBeforeInitialization methods of BeanPostProcessors
12. InitializingBean's afterPropertiesSet
13. a custom init-method definition
14. postProcessAfterInitialization methods of BeanPostProcessors

When closing a bean factory, the following lifecycle methods apply:

  1. postProcessBeforeDestruction methods of DestructionAwareBeanPostProcessors
  2. DisposableBean’s destroy
  3. a custom destroy-method definition

reference:
BeanNameAware.setBeanName, BeanClassLoaderAware.setBeanClassLoader, BeanFactoryAware.setBeanFactory, org.springframework.context.ResourceLoaderAware.setResourceLoader, org.springframework.context.ApplicationEventPublisherAware.setApplicationEventPublisher, org.springframework.context.MessageSourceAware.setMessageSource, org.springframework.context.ApplicationContextAware.setApplicationContext, org.springframework.web.context.ServletContextAware.setServletContext, org.springframework.beans.factory.config.BeanPostProcessor.postProcessBeforeInitialization, InitializingBean.afterPropertiesSet, org.springframework.beans.factory.support.RootBeanDefinition.getInitMethodName, org.springframework.beans.factory.config.BeanPostProcessor.postProcessAfterInitialization, DisposableBean.destroy, org.springframework.beans.factory.support.RootBeanDefinition.getDestroyMethodName

Guess you like

Origin blog.csdn.net/Xidian2850/article/details/127544706