Registration opportunity of autowiredannotationbeanpostprocessor under annotation development mode

  Annotation mode

Write a test method ,new Yes. AnnotationConfigApplicationContext , Appoint basePackages

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

Into the this()

It will new One AnnotatedBeanDefinitionReader

 

 new AnnotatedBeanDefinitionReader() In the process of , There is a different line of code

AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);

Continue to follow up

 

It is in this method , hold AutowiredAnnotationBeanPostProcessor Your registration is Set<BeanDefinitionHolder> in

 

 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

  This one in here AnnotationConfigUtils.registerAnnotationConfigProcessors, Are you familiar with it? Yes , I'm here again , That's it AutowiredAnnotationBeanPostProcessor Registration of

It's much more complicated than annotation , It's too deep , To make a long story short , In short ,xml The way is to create the container ,loadBeanDefinitions Registered at .

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 ~