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

How to carry out Java dynamic agent in AOP development? in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

The concept of 1.AOP: Aspect Oriented Programming is aspect-oriented programming, which can be used to dynamically add functions to the program without modifying the source code through pre-compilation and runtime dynamic proxy.

The difference between 2.OOP and AOP: if object-oriented programming is concerned with dividing requirements functions into different and relatively independent, well-encapsulated classes, and letting them have their own behavior, relying on inheritance and polymorphism to define their relationship, then aspect-oriented programming hopes to separate common requirements functions from unrelated classes.

The scope of application of 3.AOP: logging, performance statistics, security control, transaction handling, exception handling and so on.

Aspect Aspect: aspect is the modularization of a concern (crosscutting to concerns in the code), such as transaction management, logging, and rights management. Join point Joinpoint: a specific point when a program is executed, which is the execution of a method in Spring. Notification Advice: notification is the operation performed at a join point in the aspect, that is, the specific code for transaction management, logging, and so on. Pointcut Pointcut: a pointcut is a description of a particular type of join point, that is, a method that specifies a certain type of Weave notification.

There are two main styles of AOP programming in Spring: XML configuration file-based and annotation-based. Here we take annotations as an example.

Spring's pointcut matching expression uses AspectJ expressions (of course, you can also use regular expressions, and so on), which is called Aspects, as follows:

(1)? It means that it can not be configured, that is, only the name of the method name-pattern and the parameter param-pattern of the method are required. For the rest of the param-pattern, you can use * as a wildcard to indicate anything, for example: execution (* * .m (..)) Is to weave when executing an arbitrary return value, an m method in any class.

(2.) The wildcard configuration of parameters is a little more complicated, in which (..) Indicates that the parameter is 0 or more of any type; (*) represents a parameter of any type; (*, String) indicates that the first parameter is of any type, and the second parameter is of String type; nothing means no parameter.

(3) Multiple expressions can be used & &, | |,! Perform the operation because the expression returns a Boolean value.

The AOP in Spring is only for methods, and the types are pre -, post -, wrap, and exception. The AOP of Spring is done by dynamic proxy at run time, and the precompiled AOP implementation is mainly Aspect, which requires a special JAVA compiler, because it is processed by the compiler.

The concept of reflection mechanism: at run time, for any class, you can know all the properties and methods of this class; for any object, you can call any of its methods; this dynamic acquisition of information and the function of dynamically calling object methods is called the reflection mechanism of the java language.

To put it bluntly, we can load, detect, and use types that are completely unknown at run time, that is, the ability to see through arbitrary Class, even if the Class is passed to you dynamically at run time. Scope of use: when the type you want to deal with cannot be determined by the compiler, it is passed in dynamically at run time. This mechanism is adopted in current MVC frameworks. In the Struts2 framework, if we want to receive the parameter id=1&name=2&password=3 on URL, we will naturally write the following in Action: private Integer id;private String name;private String password

And their corresponding set methods, and then you can get the values of the above three fields in Action. But as a Struts2 framework, when Apache developed this framework, how did he know that we had these fields in Action? Because reflection is used in Struts2 to see through your Action.

Agent design pattern: provides a proxy for other objects to control access to this object. To put it bluntly, it is to get rid of the content and services that customers can't see or to add additional services that customers need.

Common agent design patterns:

(1.) Wrapper: the disadvantage is that when new methods are added to the Animal interface, these new methods must also be added to the wrapper class. (2.) Inheritance: the disadvantage is more obvious, that is, it is unable to implement proxies for all subclasses of the interface, which greatly reduces the scope of proxies compared with the wrapped pattern.

But either way, proxies are completed at compile time, and cannot be proxied dynamically for specified classes at run time as Spring does.

The dynamic proxy included in JAVA is based on two classes: java.lang.reflect.Proxy and java.lang.reflect.InvocationHandler, and uses JAVA reflection mechanism.

Several methods in the Proxy class are static, and in general, you can create a proxy object using the following two modes:

The first approach is more straightforward and hides the structure of the proxy $Proxy0 object, and callback InvocationHandler is where the intercept is handled.

The dynamic agent of JDK dynamically creates a $Proxy0 class that inherits Proxy and implements the interface of the target object to be proxied, but you should not try to find this class in JDK because it is generated dynamically. The structure of $Proxy0 is roughly as follows:

From the class structure above, you can understand why the second way to create a proxy object is written that way, thinking that it requires an InvocationHandler as a construction parameter.

About callback API InvocationHandler:

There is only one method invoke () that needs to be implemented, which will be activated when the target object's method is called, where you can control the target object's method call and insert some other operations (such as authentication, log, transaction management, etc.) before and after the call. The last two parameters of the Invoke () method are easy to understand, one is the Method object of the called method, and the other is the parameter of the method. The first parameter needs some attention. This proxy parameter is the dynamic proxy object we created using Proxy's static method, which is an instance of $Proxy0. (you can see that the type of proxy is indeed $Proxy0 in the breakpoint debugging of Eclipse.) Since $Proxy0 does not exist statically in JDK, you cannot cast the first parameter Object proxy to type $Proxy0, because you cannot import $Proxy0 from Classpath at all. So can we turn proxy into the interface of the target object? Because $Proxy0 implements all the interfaces of the target object, the answer is yes. But in fact, this doesn't make much sense, because you will find that after the interface is converted to the target object, any method in the interface will cause the call to invoke () to fall into a dead loop and cause a stack overflow.

This is because most of the methods of the target object are proxied. When you call the method of the target object through the converted interface of the proxy object in invoke (), it is still the proxy object, that is, when the mammal.type () method is activated, it will immediately cause the call of invoke (), and then call the mammal.type () method again. ... This puts the method call into an endless loop, just like endless recursive calls.

So what exactly is the first parameter of the invoke () method used for? In general, this parameter is not used unless you want to get a description of the class information of the proxy object, because the call to its getClass () method does not fall into a dead loop. Why wouldn't getClass ()? Because the getClass () method is final and cannot be overridden, it will not be proxied by Proxy. But do not think that Proxy can not dynamically proxy the methods of final, because Proxy faces the interface of Monkey, not Monkey itself, so even if Monkey changes the methods to final when implementing the interfaces of Mammal and Primate, it will not affect the dynamic proxy of Proxy.

The process of the Proxy proxy object is as follows

The disadvantage of JDK's dynamic proxy is that it cannot proxy classes, only interfaces. Imagine that if our Monkey does not implement any interfaces, it will not be able to do dynamic proxies in this way (in fact, because the $Proxy0 class inherits the inheritance of Proxy,JAVA and does not allow multiple parent classes). But exactly speaking, this problem should not be a disadvantage, because in a good system, every class should have an interface.

We know from the above that $Proxy0 is the type of dynamic proxy object, but since this type does not exist at all, how can we tell whether an object is a normal object or a dynamic proxy object? The isProxyClass (Class c) method is provided in the Proxy class to identify this. CGLIB is an open source dynamic proxy framework, which complements the problem that Proxy, which comes with JDK, can not implement dynamic proxy for classes. How does CGLIB break through the restrictions and dynamically proxy classes? This is because another bytecode framework, ASM, is used internally in CGLIB, similar bytecode frameworks such as Javassist, BCEL, and so on, but ASM is considered to have the best performance. But this kind of bytecode framework requires you to have a good understanding of the structure and instruction set of JAVA's Class file, and CGLIB shields these details. Because CGLIB uses ASM to manipulate bytecode directly, it is more efficient than Proxy, but the efficiency here refers to the performance of proxy objects, and Proxy is more efficient than CGLIB when creating proxy objects. The principle of CGLIB dynamic proxy is to use ASM to dynamically generate subclasses of the target object. The final method can not be overridden by subclasses, so it can not be dynamically proxied naturally, which is also a disadvantage of CGLIB. CGLIB is used internally by many open source frameworks such as Hibernate and Spring to complete the dynamic proxy of the class. The proxy-target-class of many XML configuration properties in Spring defaults to false, which means that the dynamic proxy for the target class is not enabled by default, but for the interface. In some cases, if you want to dynamically proxy the Action of Struts2 or the Controller of Spring MVC, you will find that the default Spring will report that the xxx method of $Proxy0 cannot be found. This is because we usually do not write an interface to the control layer, but directly write the request method in the implementation class, so the Proxy that comes with JDK cannot find these methods, because they are not in the interface, so you need to set proxy-target-class= "true". By introducing the class libraries of CGLIB and ASM, the dynamic agent of Spring can work normally. This is the answer to the question about how to carry out the Java dynamic agent in AOP development. I hope the above content can be of some help to everyone. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

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.