Spring AOP – Weaving mechanism

AOP

Aspect oriented programming is a paradigm that aims to increase modularity of application by separating cross cutting concerns with the application’s functionality. The aspect oriented programming addresses to the problem where it is difficult to refactor the code which is repeated in different modules/methods of your application such as logging, transaction management, or security.

So, with the help of AOP we can concentrate on the application’s main logic and keep the repeating cumbersome code in your aspect. Then it’s the work of AOP which weaves the aspects to the applications code.

Spring AOP

Spring AOP(Aspect-oriented programming) framework is used to modularize cross-cutting concerns in aspects. In simple terms, it’s just an interceptor to intercept some processes, for example, when a method is executing, Spring AOP can hijack the executing method, and add extra functionality before or after the method execution.

Weaving

Weaving is the process of linking aspects with other application types or objects to create an advised object. Weaving can be done at compile-time, at load time, or at runtime.

There are two ways in which classes and aspects can be woven: static or dynamic.

Spring AOP does dynamic weaving of aspects by creating proxy of the target objects.

It uses either JDK dynamic proxies or CGLIB to create the proxy for a given target object. (JDK dynamic proxies are preferred whenever you have a choice).

JDK Dynamic Proxy vs CGLIB Proxy

• Java Dynamic Proxy is a reflective element of the Java language that allows a user to create a proxy of an interface at runtime. Being a part of the reflection package, it is a part of Java and it ships with the JRE/JDK.
• CGLIB is a code generation library that has the capability to extend Java classes at runtime. Because of this, Spring utilizes this functionality to proxy non-interfaces for its AOP library.

If the target object to be proxied implements at least one interface then a JDK dynamic proxy will be used. All of the interfaces implemented by the target type will be proxied. If the target object does not implement any interfaces then a CGLIB proxy will be created.

To force the use of CGLIB proxying (for example, to proxy every method defined for the target object, not just those implemented by its interfaces) you can do so. However, there are some issues to consider:

• Final methods cannot be advised, as they cannot be overridden.
• You will need the CGLIB 2 binaries on your classpath, whereas dynamic proxies are available with the JDK. Spring will automatically warn you when it needs CGLIB and the CGLIB library classes are not found on the classpath.
• The constructor of your proxied object will be called twice. This is a natural consequence of the CGLIB proxy model whereby a subclass is generated for each proxied object. For each proxied instance, two objects are created: the actual proxied object and an instance of the subclass that implements the advice. This behavior is not exhibited when using JDK proxies. Usually, calling the constructor of the proxied type twice, is not an issue, as there are usually only assignments taking place and no real logic is implemented in the constructor.

To force the use of CGLIB proxies set the value of the proxy-target-class attribute of the <aop:config> element to true: