Product spring: spring boot initiates the “second battle” of bean definition registration


The previous article is very easy as a whole, because before the container is started, only one bean definition is registered, which is the main class of springboot.

OK, today we will start from the start of the container to find out the registration process of all remaining bean definitions.

The details will certainly be quite complicated. Similarly, you only need to pay attention to what you have done and not how to do it.

Take a macro view of the startup process of the container, namely the refresh method, as shown in Figure 01 below:

Just to pick up the important, it’s four big steps:

First, prepare the bean factory.

Second, call the registered bean factory postprocessor.

Third, register the bean post processor.

Fourth, instantiate all singleton beans.

The second and third of them introduce two new concepts, “bean factory postprocessor” and “bean postprocessor”.

In order to better understand them, I will go over the operation process related to beans again.

Register bean definitions – >  ->Instantiate bean – > dependent assembly – >  ->Initialize bean – >  -> OK

This is the whole process from the beginning until the bean instance is ready.among①②③It is the three embedding points reserved by spring. You can insert some user code in these places and make some customization.

amongThis is used to customize the processing bean definition when the bean instance has not been generated since the bean definition has been registered.

SurplusandBefore and after the execution of the initialization method of the bean instance, this is used to customize the processing of the bean instance.

So ① corresponds to the second one above, namely bean factory postprocessor.② And ③ correspond to the third one mentioned above, namely bean post processor.

Therefore, it can be seen that in the process of container startup, only the second one mentioned above is the bean factory postprocessor, which can match the bean definition.

It’s our next breakthrough.But someone will ask, from the beginning to now, clearly no one has registered it, why is it called here?

Eh, that’s a good question.Let’s push it backwards. First of all, it must have registered the bean factory postprocessor. Otherwise, why should we call it here? Otherwise, how are the remaining bean definitions registered in the container?

Since we (i.e. user code) are not registered, it must be that the system (i.e. framework code) is automatically registered.Well, that’s all I can do.

Then find it. It must be hidden somewhere.Find, find, find friends, find.

Finally, you can find it. It is hidden in two classes, namely, two classes responsible for registering bean definitions.

In the constructor of annotatedbeandefinitionreader, as shown in Figure 02:

In the scan method of classpathbeandefinitionscanner, as shown in Figure 03:

We find that they execute the same code, so we have to execute them twice?Ha ha, idempotent processing has been done in it.

In this method, it will be found that several beans are registered, but only one bean factory processor is registered, as shown in Figure 04:

An internal is included in its bean name, indicating that it is used internally, that is, the function of “infrastructure”, as shown in Figure 05 below:

The name of this class starts with configurationclass, indicating that it is authorized to handle the class marked with @ configuration annotation.

Think about it carefully. Let’s choose the most special and common annotation in the spring family. Anyone will choose the @ configuration annotation.

In fact, this annotation has similar functions as “configuration” and “management”.It can be said that the whole spring is built around it.

OK, now we are about to welcome the core content of this article, and work hard.As usual, it focuses on the overall process and weakens the specific implementation details.

First, take out the registered bean definition, which is the light bar commander of the main class itself.

Second, to judge whether it needs to be processed, the following conditions are met:

1) Marked with @ configuration annotation

2) Marked with @ Component annotation

3) Marked with @ componentscan annotation

4) Marked with @ import annotation

5) Marked with @ importresource annotation

6) Contains @ bean method

As long as these six conditions meet one of them, they need to be dealt with.

Since the main class of springboot is marked with @ springbootapplication annotation, the above article 1 is satisfied.

Therefore, the main class needs to be processed, which is not nonsense. At present, it only registers itself and must be processed.

New Programming Notes:Every qualified class can be regarded as a source, whose function is to contribute bean definition to the container.

Third, if the class is marked with @ Component annotation, handle its static internal (nested) class, as shown in Figure 06 below:

This is actually recursive, so the processing is the same.

Fourth, the @ propertysource annotation is processed. It can be imported into the. Properties file, which will put the property values in the file into the environment.As shown in Figure 07:

Fifthly, process the @ componentscan annotation, which will scan the specified jar package and get the bean definition from it, as shown in Figure 08 below:

Sixth, process the @ import annotation, as shown in Figure 09 below:

There are three types of content that can be introduced into this annotation:

1) Another normal class, but as @ configuration class

2) Implementation class of the importselector interface

3) Implementation class of the importbeandefinitionregister interface

Among them, the second and third are to register the bean definition by implementing the interface and writing the code, which is super flexible and can be controlled at will.

New Programming Notes:A typical use of this approach is when integrating third-party and spring frameworks.

See the following code, as shown in Figure 10:

Seventh, process the @ importresource annotation, which is used to import the. XML file. You can mix XML and annotation, as shown in Figure 11 below:

Eighth, then deal with the @ bean method in the class, as shown in Figure 1213:

Ninth, then process the default method in the interface, and the method has @ bean annotation, as shown in Figure 1415:

Finally, the parent class is processed, as shown in Figure 16 below:

Because each @ configuration class is not only its own source, but also can contribute other sources to the container, so it is recursive in general.

In the process, we have done a good job of anti duplication processing, so there will be no duplicate registration.

All of the above are actually the logic in the configuration class postprocessor class.

It is not only a bean factory postprocessor, but also a postprocessor dedicated to registering bean definitions.

This class is called when the container starts, so the bean definitions of other classes are registered in the container.

>>>Article series on spring<<<


Spring: the foundation of Empire

Product spring: bean definition goes to Liangshan

Product spring: the “advanced productivity” used in bean definition

Tasting spring: annotation is finally “successful”

Pin spring: craftsman’s “blessing” on annotation

Product spring: is there any essential difference between spring boot and spring?

Product spring: two “pioneers” responsible for bean definition registration

Product spring: spring boot easily wins the “first stage” of bean definition registration


authorIt’s work over10 yearsNow he’s an architect. Like to research technology, advocate simple and happy.The pursuit of easy to understand language interpretation technology, hope that all readers can understand and remember.Below is the public code and the two-dimensional code of knowledge planet. Welcome to pay attention!