This is the 13th day of my participation in the More text Challenge. For details, see more text Challenge

As mentioned earlier, AOP joinPoints can come in many types, such as constructor invocation, field setting and fetching, method invocation, method execution, and so on. However, in Spring AOP, only Joinpoint at the method level is supported. More specifically, only JoinPoints of method execution types are supported.

Although Spring AOP only provides method interception, in real life this can cover 80% of development requirements. So, let’s not worry too much about Spring AOP’s capabilities

Spring AOP is this way for several reasons:

1.Spring AOP wants to provide a simple yet powerful AOP framework, but it doesn’t want to make the framework bloated by being so large. Wouldn’t it be great to be able to get 80% of your needs supported for only 20% of your efforts?

2. If you provide this level of interception support for joinPoints at the property level of the class, you break the object-oriented encapsulation, and you can do the same thing by intercepting setter and getter methods.

3. If your application needs are so specific that they completely exceed the 80% support provided by the Spring AOP framework, you may want to turn to other existing AOP implementation products, such as AspectJ. AspectJ is by far the most well-supported AOP product in the Java platform, and Spring AOP also provides support for AspectJ.

PointCut

Spring in the interface definition org. Springframework. Aop) Pointcut as the top of its all Pointcut in the aop framework of abstraction, the interface defines two methods used to help capture system in corresponding Jointpoint, An instance of the TruePointcut type is provided. If the Pointcut is of type TruePointcut, all objects in the system and all supported JoinPoints on the object will be matched by default. . Org. Springframework. Aop Pointcut are defined as follows:

public interface Pointcut{
    ClassFilter getClassFilter(a);
    MethodMatcher getMethodMatcher(a);
    Pointcut True = TruePointcut.INSTANCE;
}
Copy the code

ClassFilter and MethodMatcher are used to match the objects to be woven into and the corresponding methods, respectively. The reason for defining type matches and method matches separately is that different levels of match definitions can be reused, combined at different or the same levels, or forced to overwrite only the corresponding method definition for a subclass.

The ClassFilter interface matches the Joinpoin objects at the Class level. The ClassFilter interface is defined as follows:

public interface ClassFilter {
    boolean matches(Class clazz);
    ClassFilter TRUE = TrueClassFilter.INSTANCE;
}
Copy the code

The matches method will return true if the Class type of the target object matches the type specified by the Pointcut. Otherwise, it will return false, which means that the target object of this type will not be woven. For example, if we only want to weave a Class of type Foo in our system, Then we can define ClassFilter as follows:

public class FooClassFilter {
    public boolean matches(Class clazz){
        returnFoo.class.equals(clazz); }}Copy the code

Compared to the simple definition of ClassFilter, MethodMatcher is much more complex. After all, Spring primarily supports methoch-level interception. MethodMatcher is defined as follows:

public interface MethodMatcher {
    boolean matches(Method method, Class targetClass);
    boolean isRuntime(a);
    boolean matches(Method method, Class targetClass, Object[] args);
    MethodMatcher TRUE = TrueMethodMatcher.INSTANCE;
}
Copy the code

MethodMatcher defines two matches methods through overloading, and the boundary between the two methods is the isRuntime() method. When intercepting an object-specific method, you can either ignore the parameters passed in by the caller each time the method is executed, or you can check the method call parameters each time to enforce the interception condition. Suppose we intercept the following method:

public boolean login(String username, String password);
Copy the code

If you just want to insert the counting function before the login method, the parameters of the login method are ignored for Joinpoint capture. If you want to treat a user individually when they log in, such as not logging them in or granting them special privileges, then this parameter must be considered when matching Joinpoint.

In the former case, isRuntime returns false, indicating that no specific Joinpoint method arguments are considered. This type of MethodMatcher is called StaticMethodMatcher. Because you don’t have to check the parameters every time, the results for the same type of method matches can be cached within the framework to improve performance.

2. When isRuntime returns true, it means that this MethodMatcher will check the parameters of the method call for matching each time. This type of MethodMatcher is called DynamicMethodMatcher. Because the method parameters are checked each time, the result of the match cannot be cached, so the match is less efficient than StaticMethodMatcher.

Advice

In Spring, Advice can be divided into two categories, per-class Advice and per-instance Advice, based on whether its own instance can be shared among all instances of the target object class.

Advice of the per-class type

Per-class Advice means that instances of this type of Advice can be shared among all instances of the target object class. This type of Advice usually provides only method interception and does not save any state or add new features to the target object class.

1.BeforeAdvice: Checks or initializes the specified paths of file systems.

2.ThrowsAdvice: Monitors running exceptions in the system. Once an exception is detected, notify system monitoring personnel or operation personnel in a certain way immediately.

3. AfterReturningAdvice: use the scene: the state of the authentication system in order to facilitate operations personnel, FX batch program after the completion of a normal toward the specified in the table inserted into the running state of the database, operating personnel can by verifying the condition judgment corresponding batch processing tasks to be executed successfully.

4.AroundAdvice: used for system security verification and check, system performance detection, simple log recording, and adding additional system behaviors.

Advice of the per-instance type

Introduction is the only per-instance Advice in Spring AOP.

Introduction allows you to add new attributes and behaviors to the target class without changing the definition of the target class. This is just like us developers, if the company is tight, there is no test staff, then, usually give us a “test staff” hat, let us test the system at the same time, in fact, you are still you, just a little more things.

In Spring, adding new properties and behaviors to a target object must declare the corresponding interface and the corresponding implementation. This, in turn, attaches the new interface definition and the logic in the implementation class to the target object through a specific interceptor. After that, the target object (or rather the proxy object for the target object) has the new state and behavior. This specific blocker is org. Springframework. Aop. IntroductionInterceptor, its definition is as follows:

public interface IntroductionInterceptor extends MethodInterceptor.DynamicIntroductionAdvice {
    public interface DynamicIntroductionAdvice extends Advice {
        boolean implementsInterface(Class intf); }}Copy the code

The role of the Ordered

It is rare for a system to have a single crosscutting concern; most of the time, there will be multiple crosscutting concerns to deal with, and multiple Advisors will be present in the system implementation. When some of the Advisor pointcuts match the same Joinpoint, multiple Advice crosscutting logic is executed at the same Joinpoint. If there is no strong priority dependency between the Advice to which these Advisors are associated, it makes no difference who executes first and who executes last. If the Advice logic that needs to be executed at the same Joinpoint has a priority dependency, we need to intervene.

When Spring processes multiple Advisors at the Joint Point, it actually executes them in the specified order and priority. The smaller the order, the higher the priority. We can specify starting at 0 or 1, because sequence numbers less than 0 are used internally by the Spring AOP framework in principle. By default, we don’t explicitly specify the order in which each Advisor is executed, so Spring applies them in the order in which they are declared, with the first declaring having the lowest order but the highest priority, followed by the second.