Make a qualified program analysis of the ape Spring AOP source code (18) Spring AOP Development Big battle Source code parsing

In fact, the value of the previous article is very small, but also the suspicion of repeating the wheel, there are many examples of online AOP, the list, in fact, I want to say is not this, I want to say is the last section of the Spring configuration file:

We're not using the main implementations of the AOP we analyzed in the last few sections: Proxyfactorybean.java, Proxyfactory.java, Aspectjproxyfactory.java, in our configuration file, There is no display to configure these classes, so how did spring do it?

You can think of how spring is going to kill the target object? Who the hell is the real murderer (Proxyfactorybean?) Proxyfactory? aspectjproxyfactory)? When did you kill it (which phase of the Spring IOC container initialization is acting?). ）

Actually, there are several problems here.

How many instances are there in the ①spring container?

(In fact, this is a good solution, we just need to open the Refresh method, see how many objects in the Beandefinitionmap in Beanfactory can be known)

When did ②spring end up rescue, that is, at what stage of the spring container initialization phase was our target object replaced by an agent?

On this issue, I think we should give our own answer, remember when we analyze the spring IoC source code, we say that we want to modify a bean basically only 2 stages, or 3 small segments

The first is in the implementation of the beanfactorypostprocessor phase, we have previously said that this stage is to modify the Beandefinition, modified beandefinition will directly modify the generation of this bean, So this phase is likely to be a proxy place, but careful analysis, should not, if at this stage agent, then if we are the target object of the agent implemented other interfaces, such as Initializingbean, or define Init-method these methods, Is it not going to be executed? So it should not be.

Then the second biggest doubt is the beanpostprocessor phase, this interface is divided into 2 stages, you should remember the interface of the core interface:

In fact, these 2 methods can be modified directly to the bean, but the most likely is postprocessafterinitialization this interface, Because we've analyzed postprocessafterinitialization before. This method is the last execution during the bean initialization, that is, if spring secretly replaces the bean at this stage, it is transparent to us, completely without feeling , because some of the bean instantiation operations are done.

Well, analysis now, actually, I just want to say that what we're going to do now is we look at the IOC Refresh method, and look at a few points and know the principles of an IOC-configured AOP

① look at the beandefinition.

② See beanfactorypostprocessor this deal

③ look at the registration of Beanpostprocessor

④ See what happens to our target object at this stage of postprocessafterinitialization?

⑤ See how our Advisor is generated, what the agent does

Well, let's look at the 1th first:

First of all, the Beandefinitionmap object in Beanfactory is 9, except for the 2 defined on our materializing, and 7 beans that we do not know are also generated (about how these 7 are generated, and this is not a detailed one here. Mainly according to the spring XML file namespace to do the conversion and then as a normal bean processing, the most doubtful here is the red mark in the top 2 (the name will know)

We went on to the 2nd:

When our debug has passed Beanfactorypostprocessor's execution, we look at Beandefinitionmap:

It doesn't seem to have been modified to show that the murderer is not beanfactorypostprocessor

OK, let's go to the 4th (3rd last), we'll hit the breakpoint at Abstractautowirecapablebeanfactory.java's 1518 line (spring.3.2.5)

Enter the detailed method:

Okay, let's take a look at the Yizhao of our target, and wait for the murderer to be brutally murdered.

The objects in the bean until this side are still our bussinessserviceimpl.

Next the murder is about to begin when we execute to a name called org.springframework.aop.framework.autoproxy.abstractadvisorautoproxycreator$ When the Beanfactoryadvisorretrievalhelperadapter, Let's go into the postprocessafterinitialization. This method: Abstractautoproxycreator.java Postprocessafterinitialization method,

Enter the Wrapifnecessary

Well, let's see what the hell we're going to do with that. Enter the Createproxy method:

The original knife is proxyfactory, haha ~ finally find out why

Now that we know who the murderer is and where it was killed, the last question remains, how did the murderer sneak into the victim's room?

We're still going back to our just didn't see? 3rd: Let's look at Beanpostprocessor's registration and go back to the Registerbeanpostprocessors method in the Refresh method

See, the killer was sneaking into the room at this time, and when spring is instantiated, the target object is

So far, we have basically known the basic process of homicide, but the details we have not analyzed, such as how the advisor generated, how did the murderer know that in the night is to kill Bussinessservice? Please take a look at all of them.

This is the end of the day, everybody. end~, south of the Great God

Make a qualified program analysis of the ape Spring AOP source code (18) Spring AOP Development Big battle Source code parsing