Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "the method of building Bean in SpringBoot and the wrong posture description of loading sequence". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

i. Environment building

Create a maven project with the following pom file (specific project code can be obtained at the end of the article)

Org.springframework.boot spring-boot-starter-parent 2.1.7 UTF-8 UTF-8 Finchley.RELEASE 1.8 org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-maven-plugin spring-milestones Spring Milestones https://repo.spring.io/milestone false II. Wrong posture

Below we will introduce the incorrect use of two typical annotations, one @ Order and one @ AutoConfigureOrder.

I. @ Ordererr.case1: add Order annotations to the class

A common misconception is that by adding this Order annotation to the class, you can specify the initialization order between bean. The smaller the order value, the higher the priority. Let's actually test whether this is the case.

We create two DemoBean to specify a different Order order

@ Order (4) @ Componentpublic class BaseDemo1 {private String name = "base demo 1"; public BaseDemo1 () {System.out.println (name);}} @ Order (3) @ Componentpublic class BaseDemo2 {private String name = "base demo 2"; public BaseDemo2 () {System.out.println (name);}}

According to the previous point of view, if the value of orde is low, the priority is high, so BaseDemo2 should be initialized first and tested in practice. The output is as follows

Err.case2: add @ Order to the Bean declaration method in the configuration class

In addition to the automatic scanning above, another way for Bean is to annotate @ Bean. Let's demonstrate the error case that specifies the loading order of bean in the configuration class.

Similarly, we create two new test bean

Public class BaseDemo3 {private String name = "base demo 3"; public BaseDemo3 () {System.out.println (name);}} public class BaseDemo4 {private String name = "base demo 4"; public BaseDemo4 () {System.out.println (name);}}

Next, define bean in the configuration class

Configurationpublic class ErrorDemoAutoConf {@ Order (2) @ Bean public BaseDemo3 baseDemo3 () {return new BaseDemo3 ();} @ Order (1) @ Bean public BaseDemo4 baseDemo4 () {return new BaseDemo4 ();}}

Similarly, if the @ Order annotation is valid, then BaseDemo4 should be initialized first

From the actual test output above, we can see that the @ Order annotation does not work in the above way. If interested students can try to reverse the order of the two methods in the above configuration class, you will find that BaseDemo4 loads first.

Err.case3: @ Order Annotation Decoration configuration Class

This is also a common error case, which thinks that the @ Order annotation is used to specify the loading order of configuration classes, but is this really the case?

We create two configuration classes for the test

@ Order (1) @ Configurationpublic class AConf {public AConf () {System.out.println ("AConf init!");} @ Order (0) @ Configurationpublic class BConf {public BConf () {System.out.println ("BConf init");}}

If the @ Order annotation takes effect, then the BConf configuration class will be initialized first, so let's test it.

As can be seen from the above results, BConf is not loaded first; of course, this use posture is actually no different from the first error case. The configuration class is also bean, which does not take effect before, and certainly will not take effect here.

So is it because our understanding is incorrect? in fact, after the @ Order is placed on the configuration class, does the Bean defined in this configuration class take precedence over the Bean defined in another configuration class?

Similarly, we test this case, and we define three bean and two conf.

Public class Demo1 {private String name = "conf demo bean 1"; public Demo1 () {System.out.println (name);}} public class Demo2 {private String name = "conf demo bean 2"; public Demo2 () {System.out.println (name);}} public class Demo3 {private String name = "conf demo bean 3"; public Demo3 () {System.out.println (name);}}

Then we put Demo1 and Demo3 in one configuration and Demo2 in another.

@ Order (2) @ Configurationpublic class AConf1 {@ Bean public Demo1 demo1 () {return new Demo1 ();} @ Bean public Demo3 demo3 () {return new Demo3 ();} @ Order (1) @ Configurationpublic class BConf1 {@ Bean public Demo2 demo2 () {return new Demo2 ();}

If the @ Order annotation actually controls the loading order of the Bean in the configuration class, then the Bean in BConf1 should be loaded first, that is, Demo2 will take precedence over Demo1 and Demo3. Actually test it, as shown in

The output above is not what we expected, so the @ Order annotation to determine the order of the configuration classes is also incorrect.

2. @ AutoConfigureOrder

From a naming point of view, this annotation is used to specify the order of configuration classes, but there is also a lot of misuse of this annotation, and most of the misuse lies in not really understanding its usage scenario.

Let's demonstrate the wrong use of case.

Create two new configuration classes in the project and use annotations directly

@ Configuration@AutoConfigureOrder (1) public class AConf2 {public AConf2 () {System.out.println ("AConf2 init!");} @ Configuration@AutoConfigureOrder (- 1) public class BConf2 {public BConf2 () {System.out.println ("B conf2 init!");}}

When the annotation takes effect, BConf will load it first.

Judging from the output, it is not what we expected; does this annotation act on the order of the Bean in the configuration class, rather than on the configuration class itself?

Similarly, let's design a case to verify it.

Public class DemoA {private String name = "conf demo bean A"; public DemoA () {System.out.println (name);}} public class DemoB {private String name = "conf demo bean B"; public DemoB () {System.out.println (name);}} public class DemoC {private String name = "conf demo bean C"; public DemoC () {System.out.println (name);}}

Corresponding configuration class

@ Configuration@AutoConfigureOrder (1) public class AConf3 {@ Bean public DemoA demoA () {return new DemoA ();} @ Bean public DemoC demoC () {return new DemoC ();} @ Configuration@AutoConfigureOrder (- 1) public class BConf3 {@ Bean public DemoB demoB () {return new DemoB ();}

If the DemoB is loaded, the above point of view is wrong, and the measured results are as follows

So here's the problem: the @ AutoConfigureOrder annotation doesn't specify the order of the configuration classes, so why do you call it that? The essence of existence is misleading, not!

Next let's take a look at the correct use of @ Order and @ AutoConfigureOrder

iii. Instructions for use 1. @ Order

Take a look at the official note of this note first.

{@ code @ Order} defines the sort order for an annotated component. Since Spring 4, annotation-based ordering is supported for many kinds of components in Spring, even for collection injection where the order values of the target components are taken into account (either from their target class or from their {@ code @ Bean} method). While such order values may influence priorities at injection points, please be aware that they do not influence singleton startup order which is an orthogonal concern determined by dependency relationships and {@ code @ DependsOn} declarations (influencing a runtime-determined dependency graph).

At first, Order annotations are used to specify the priority of sections; after 4. 0, its function has been enhanced to specify the order of bean in the collection when supporting the injection of collections.

And specifically pointed out that it has no effect on the order between the bean of the instance; this sentence can also be verified by our above test.

Next we need to look at the scenario in which the order is specified when the collection is injected through the @ Order annotation

First, let's define two Bean implementations of the same interface and add the @ Order annotation

Public interface IBean {} @ Order (2) @ Componentpublic class AnoBean1 implements IBean {private String name = "ano order bean 1"; public AnoBean1 () {System.out.println (name);}} @ Order (1) @ Componentpublic class AnoBean2 implements IBean {private String name = "ano order bean 2"; public AnoBean2 () {System.out.println (name);}}

Then we test the bean and inject the list of IBean. We need to test whether the order of the Bean in this list is consistent with the @ Order rule we defined.

@ Componentpublic class AnoTestBean {public AnoTestBean (List anoBeanList) {for (IBean bean: anoBeanList) {System.out.println ("in ano testBean:" + bean.getClass () .getName ());}

According to our expectations, anoBean2 should be in front of the anoBeanList collection

From the output above, we can also see that the order in the list is the same as we expected, and AnoOrderBean1 has nothing to do with the loading order and comments of AnoOrderBean2.

2. @ AutoConfigureOrder

This annotation is used to specify the loading order of the configuration file, but it did not work in the previous test, so what is the correct posture?

@ AutoConfigureOrder applies to the order of AutoConfig in externally dependent packages, but cannot be used to specify the order within this package

To verify the above statement, we create two new projects again and specify the order of the automatic configuration classes.

The configuration of project 1 is as follows:

@ AutoConfigureOrder (1) @ Configuration@ComponentScan (value = {"com.git.hui.boot.order.addition"}) public class AdditionOrderConf {public AdditionOrderConf () {System.out.println ("additionOrderConf initabilities!");}}

Note that if the automatic configuration class is to be loaded correctly, it needs to be defined in the / META-INF/spring.factories file of the project.

Org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.git.hui.boot.order.addition.AdditionOrderConf

The configuration of project 2 is as follows:

@ Configuration@AutoConfigureOrder (- 1) @ ComponentScan ("com.git.hui.boot.order.addition2") public class AdditionOrderConf2 {public AdditionOrderConf2 () {System.out.println ("additionOrderConf2 initableness!");}}

Then we add a configuration inside the project

@ AutoConfigureOrder (10) @ Configurationpublic class OrderConf {public OrderConf () {System.out.println ("inner order conf initabilities!");}}

Because annotations apply to the order of automatic configuration classes in external dependency packages, of the above three configuration classes, AdditionOrderConf2 comes before AdditionOrderConf1 if correct However, OrderConf will not be affected by annotations. By default, internally defined configuration classes are better than external dependencies, which can be confirmed by the following output (of course, in order to verify this, we should also adjust the order of the next two external project configuration classes and see if the loading order changes accordingly, which we omitted here)

This is the end of the introduction of "wrong posture instructions for building Bean and loading sequence in SpringBoot". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.