We’ve all being there, we’ve all had this on a project once or maybe even more times. The assignment is to build an application but there is no data for you to work with. There could be any number of reasons this could be the case - to name a few, the web-service that should be connected is not done in time, the database migration is postponed. Then someone has to create database scripts with test data, or implement a test web-services. This is all a waste of time.

But lucky for you now there is a solution.
(more...)

Filed under AOP, Frameworks, Java, Spring, Testing | 2 Comments »

Recently I wanted to add an aspect to some domain object, so that it was saved, the moment it changed state. However, after adding this aspect, the whole build of course failed, because a lot of the unit tests weren't expecting the calls which were now woven into the domain object.
(more...)

Filed under AOP, Java, Spring, Testing | 5 Comments »

Everybody loves POJO's. Ever since Martin Fowler, Rebecca Parsons, and Josh MacKenzie coined the term back in 2000, the idea has taken the Java world by storm. Successful frameworks like Spring and Hibernate have centered on POJO's to make J2EE development a whole lot easier.

Since then JDK 1.5 came along and brought us annotations. And now everybody's going crazy again. And by claiming to support POJO's old-skool tech is now trying to become fashionable again.

Although I could not find an official definition of POJO, I think we can generalize from Martin Fowler's original definition that a POJO is not an EJB to a POJO is a Java object that is not tied to any specific framework, and therefore can be used by multiple frameworks in different situations and configurations. If you accept this definition, you'd have to agree this annotated POJO craze is silly.

(more...)

Filed under AOP, Hibernate, Java, Spring | 4 Comments »

Proxy-based AOP frameworks like the one in the Spring Framework have a not oft discussed problem. When a method in a class invokes another method in the same class (or a superclass), any interceptors on that second method are not executed. This unexpected behaviour can have serious consequences when the interceptor delivers important services like transactions or security.

Let's say we are implementing an application for a bank where only certain employees are allowed to perform a credit check on suspect transaction, e.g. those exceeding 1 million euros. Using Aspect Oriented Programming this can be implemented as follows:

When processed by AspectJ's precompiler, the following woven class is output:

As you can see in the picture, when the method processPayment is invoked, the correct security check is performed when the checkCreditRating method is invoked.

However, that precompilation step was perceived as complicated and hard to integrate into the build proces (and not every IDE has appropiate plugins). This led to the appearance of proxy-based AOP solutions such as dynaop and Spring's AOP framework. A precompilation step is no longer necessary. Instead, a proxy is created on the fly. This proxy performs the functionality defined in the aspect before (and after) invoking the method in the original object:

Apart from only offering method interception instead of the full range of AOP functionality, this approach has one other, not often discussed, drawback. When invoking the checkCreditRating method on the proxy, the security check is correctly performed. However, when invoking the processPayment method on the proxy (see the picture), control is passed to the processPayment method in the original object which invokes this.checkCreditRating() directly, thereby bypassing the security check. This occurs because this in the original object refers to that object itself instead of the proxy.

Other functionality that assumes the identity of the proxy and the identity of the original object are identical will fail too. As mentioned in GoF on page 178 when discussing the Decorator pattern:

3. A decorator and its component aren't identical. A decorator acts as a transparent enclosure. But from an object identity point of view, a decorated component is not identical to the component itself. Hence you shouldn't rely on object identity when you use decorators.

This is an unexpected result of the proxy-based implementation of AOP and one that you need to be especially aware of when implementing important functionality in a aspect!

Filed under AOP, Java, Spring | 8 Comments »