This is a series and it would make a lot of sense if read in a sequence. You can find all the posts under the heading “Spring Beginners to Professionals“. This is the second post of the series.
Before diving into the Spring Framework, I would like to explain few generic concepts which are used all around Spring and a good understanding of these concepts can make our learning process smoother. The First one is Aspect Oriented Programming. This post is dedicated for understanding the concepts of Aspect Oriented Programming, primarily from the standpoint of Spring Framework.
Aspect Oriented Programming
An aspect is a feature of a program which is not considered to be the program’s primary function. An aspect generally cross cuts the core concerns of a program. This also means that if an aspect means a piece of code, then it will be executed for one or more core concerns.
For e.g.: Logging can be considered as an aspect, Similarly security can be another aspect and so on. This is pretty different from what we learn in Object Oriented Programming, where the main focus is on separation of concerns.
What do we do with these Aspects?
In a typical application, the core concerns are already implemented in terms of business logic. For e.g. a shopping cart application, where the primary concern is to manage one or more
shopping carts per user.
Now if we want to log all the activities of the user like item added to cart, item deleted from the cart, purchase made etc. There are two possibilities:
- We could have either hard coded these log statements in the business code or
- The smarter way would have been to intercept these method invocations to the target object (in this case the shopping cart object) and execute the aspect’s code and then propagate the invocation to the target object.
Most of the time, the first option is not actually an option if you are dealing with some legacy code. Aspects are the only option left to you. Here the idea is to execute the aspect code wherever we want within our core application code. Or may I rephrase it to “Convert our Aspect Oriented Code to Object Oriented Code”.
How do we make this possible?
Consider a black box, which takes in the application code and the aspect code and transforms the inputs to return back one code which has both the functionalities in built. The black box is called an aspect weaver and its job is to convert the aspect oriented code to object oriented code.
In technical terms, the process is called weaving. Aspects can be woven into any code at three levels, based on the tools available and the support from the language.
Source Level Weaving
Also known as the compile time weaving, in which the weaver has access to the application’s source code as well as the aspect’s code. It combines both the code and compiles them to produce class files for the combined code which is compatible with our object oriented paradigm.
Byte Code Weaving
In this form of weaving, the aspect is woven into the well know byte code generated out of the application’s source code using the java compiler or similar programs. This kind of weaving can deliver the Object Oriented Code at the build time.
If the weave model is a per class, it can deliver the Object Oriented Code later in the cycle when the classes are loaded by the class loaders in the underlying JVM. And this is generally termed as Load Time Weaving. Notice that in this type of weaving the weaver has to deal with class loader hierarchies and sometimes tweak the class loading process.
Deploy Time Weaving
This form of weaving is also known as run time weaving. It is done inside the JVM when the classes are already defined by the class loaders, hence no interference with the class loaders is actually required, neither is the generated class files patched as in the previous approach.
This is achieved by a special technique called proxying.
The target class (application’s classes) is sub classed and modifications in the code is achieved using method overriding. The subclass is termed as a proxy. Subclass based proxies are mostly CGLIB proxies. CGLIB is the library used for generating the sub classes.
If the target object implements an interface, then the interface is implemented and combined with the target object’s code and modification is done in the new implementation. The newly implemented class is called the proxy. Interface based proxies are created using JDK Dynamic Proxies.
One drawback of JDK Dynamic Proxies is that they cannot be casted back to the target class, because they are not sub classed, they just happen to implement the same interfaces. A debugging tip! If you are facing some class cast exceptions in Spring and you believe everything else is pretty neat, then you can give it a shot debugging on these lines.
Aspect Oriented Programming is heavily used in the cores of Spring Framework. However, you can also find many more usages across different frameworks like Hibernate and few more. There are many implementations of AOP.
In the next post, we will focus on another very important concepts which is a pre-requisite for this course. The concept is called annotations.