An article will take you to play with Spring beans in the ultimate skill

Preface

In the previous article, it is mentioned that through interfaces such as InitializingBean and Disposable, some custom operations can be made for bean initialization and destruction. One thing to note is that it is just an operation after the bean is instantiated by a container. In the world of spring, if you want to do something about the instantiation process, as an ordinary business developer, obviously you don’t need to inherit ApplicationContext or BeanFactory, because spring container provides us with some interfaces, allowing us to extend the initialization operation of beans by BeanFactory in the form of plug-ins, including our protagonist today - BeanPostProcessor (hereinafter referred to as bpp) interface.

Source code, take a sneak peek

This usage is very simple. It only has two methods. We implement our own BeanPostProcessor, and Spring can automatically register it into the container.

where the before method is executed after bean instantiation, after property setting but before initialization method; after method is executed after various initialization methods.

Speaking of this, some people may wonder, what is the difference between this and other initialization interfaces in the life cycle? Other initialization methods can also modify beans. This question is good. Let's talk about the essential difference between this interface and the InitializingBean Disposable interface and the customized init destroy method.

• The two methods of bpp have the return value Object, which is precisely the key to the problem. This bean is the bean we want to modify. In this way, we can modify the bean instance itself, replace it, or wrap it into a proxy bean (this is how the AOP mechanism in Spring does), while the return of other initialization interfaces is void, so they can only modify the state of the bean in theory, and what they can do is quite limited.
• bpp is executed by Container in the form of an extension plug-in, and does not need the bean itself to do anything (the bean itself does not need to implement this interface), so this plug-in is not coupled with the bean in code.
• The execution method is also completely different. bpp is an extension of Spring container. During the process of initializing beans in the container, each bean will be executed once. Since the initialization interface is implemented by a specific bean, it has nothing to do with other beans and is only executed on the beans of this type. In short, although the operations on the bean are performed by the container, bpp is the behavior of the extended container itself, and the initialization interface is executed by the container after the behavior of the extended bean.

There are two special bpps here. I have to say that if you need to customize an annotation similar to @Autowire or @Inject's injection function (you may use InjectionMetadata), ordinary bpps may not meet your needs, and you may use two special bpps.

MergedBeanDefinitionPostProcessor (hereinafter referred to as mbdpp)

InstantiationAwareBeanPostProcessor (hereinafter referred to as iabpp)

They all inherit from bpp, but the entry point in the process of creating spring beans is different from ordinary bpp.

InstantiationAwareBeanPostProcessor Interface

See the comments

postProcessBeforeInstantiation method

Check the createBean method of AbstractAutowireCapableBeanFactory (this method is the core method of creating beans in Spring containers). You can see that postProcessBeforeInstantiation is before bean instantiation, postProcessAfterInstantiation is set after instantiation and before autowire injection. It is generally used internally in the spring framework, but there is great potential here. Use postProcessBeforeInstantiation to generate proxy objects (the general method is to make the postProcessorBeforeInstantiation return not null, which will interrupt the subsequent process of creating bean instances. The object returned by this method will be used as the bean instance). See the source code:

postProcessPropertyValues method

Use postProcessPropertyValues to complete various operations on properties, parsing metadata in annotations, etc. Spring's @Autowire injection, JSR330's @Inject, and JSR250's @Resource and other injection operations are all completed through this method.

This interface is used in spring, and students who are interested can read the source code. The following are two typical implementations.

AutowiredAnnotationBeanPostProcessor
AbstractAutoProxyCreator

MergedBeanDefinitionPostProcessor Interface

This interface passes in a RootBeanDefinition, which allows us to modify the definition of the bean. @AutuwiredAnnotationBeanPostProcessor uses this method to check and register the members that need to be injected.

BeanFactoryPostProcessor(bfpp)

In addition to BeanPostProcessor, there is another kind of thing that everyone knows, that is, BeanFactoryPostProcessor

bfpp is an important extension plugin for beanFactory and can be customized with beanDefinition. Its main difference from bpp is:

• bpp is a processed bean instance, bfpp is the definition of processed bean
• bfpp can read and modify the definition of beans (BeanDefinition). For example, the placeholder ${} used in the configuration is implemented by PropertyPlaceholderConfigurer by implementing bfpp.
• BPP processes examples of beans that are freshly released and have set properties (except for two special bpps mentioned above, iabpp and mdbpp)

Okay, after saying so much, let’s take a look at the general flowchart of Spring’s bean creation. Only the more critical nodes are marked here.

Summarize

The above is the entire content of this article. I hope that the content of this article has certain reference value for everyone's study or work. If you have any questions, you can leave a message to communicate. Thank you for your support to Wulin.com.