Registration opportunity of autowiredannotationbeanpostprocessor in XML development mode

AutowiredAnnotationBeanPostProcessor It's the realization of @Autowired The key to , When was it added to sping In container ？

xml The way

In the use of xml In the process of mode development , Our program entry is generally ClassPathXmlApplicationContext

	@Test
	public void test() throws Exception{
		ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("spring-test.xml");

		Student student = (Student)applicationContext.getBean("student");
		System.out.println(student.getUsername()+"   "+student.getPassword());


	}

establish ClassPathXmlApplicationContext when , Would call this Constructors

  Call the parent constructor in the constructor , Finish loading some properties , And the resolution of the configuration file path , Then get to the point ——refresh()

 

At the core refresh() In the method , One step is to create BeanFactory

 

establish BeanFactory after , It incidentally brings our xml The configuration file is also parsed

establish BeanFactory, then loadBeanDefinitions

 

loadBeanDefinitions The process is complicated , Those who are interested can go line by line degbug Source code , Here are a few key steps

  Several of the same name loadBeanDefinitions Tune in and out , It's best to transfer to a real worker doLoadBeanDefinitions

 loadBeanDefinitions Not the focus of attention this time ,doLoadBeanDefinitions There is no need to delve into the details of , What's important is that doLoadBeanDefinitions After completion , I just got one Document Get object , It's not what we want bean Defining information , namely BeanDefinition, So we went on a call registerBeanDefinitions Steps for

  In this registerBeanDefinitions In the process of , Nine twists and eighteen turns

  Also tone do The first method is to do real work

  Start parsing the previous Document 了

  There are two types of parsed tags , One is DefaultElement, One is CustomElement

  A digression , What is? DefaultElement, These four are , Namely import、alias、bean、beans, let me put it another way , Except for these four , Everything else is CustomElement

  In my test environment , The first label is context, Nature is walking parseCustomElement

 

Then continue to analyze

  Transfer to NamespaceHandlerSupport Of parse Method

  Further down is ComponentScanBeanDefinitionParser Of parse Method , It's finally over , The tag is parsed and encapsulated into BeanDefinitionHolder, Then there is another action registerComponents

 

It's this humble little action ,registerComponents, It contains mystery

  In this, a AnnotationConfigUtils.registerAnnotationConfigProcessors, It's done here AutowiredAnnotationBeanPostProcessor Registration of

 

To make a long story short , In short , After creating the container ,loadBeanDefinitions Registered at .

Annotation mode

The same whole test method , This time new Yes. AnnotationConfigApplicationContext Not the one above ClassPathXmlApplicationContext

	@Test
	public void test() {
		AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext("com.zubus.bean");
		BeforeInstantiation bean = ac.getBean(BeforeInstantiation.class);
		bean.doSomeThing();
	}

It's a different route , Into the this()

 

It will new One AnnotatedBeanDefinitionReader

 

 new AnnotatedBeanDefinitionReader() There is a familiar figure in the process of

AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);

Is it with the above xml The resolved registerComponents It's as like as two peas

 

you 're right , It's right here

 

  thus , Under two development modes AutowiredAnnotationBeanPostProcessor We have mastered the registration time

This is just registration , The next step is to analyze where it was not created as an object

The next step is to analyze where it is called and executed

Please look at the next breakdown ~