Jasypt : encryption with great support for Hibernate and Spring

For my petproject, I was in the need of encrypting a few database columns. There is of course the full-fledged solution of Acegi Spring Security, but since I only needed encryption of a few database columns, I decided to go for Jasypt.

Using the following tutorial, I easily integrated Jasypt with my existing Spring/Hibernate/Echo2 stack. The only problem I encountered was a JCE problem, since I hadn't installed the unlimited
strength policy files in the jre/lib/security directory. Since unlimited strength, was not what I needed anyway, I switched the algorithm PBEWithMD5AndTripleDES to PBEWithMD5AndDES and my transparantly encrypted database columns were a fact.

The only drawback I encountered was the dependency of Jasypt on the external library International Components for Unicode (ICU), which is over 4 megabyte. However, despite this fact, Jasypt is a great library, which gets you up to speed really fast.

Handle Runtime Exceptions In Echo2

I was looking for a transparant mechanism to handle runtime exceptions in Echo2. Apparently Echo2 does not provide any hook for gracefully handling runtime exceptions due to the following posts. Since one solution lost access to the current Application Instance and the other involved changing Echo2 source code, I have found my own solution to this problem:

public class ExceptionalUpdateManager extends UpdateManager{
private static final long serialVersionUID = 1L;

public ExceptionalUpdateManager(ApplicationInstance applicationInstance) {
super(applicationInstance);
}

public void processClientUpdates()
{
try{
super.processClientUpdates();
}catch(AbstractHrutilRuntimeException exception){
//Hook : I show an error popup with the translation of the error code.
TopContentPane.getTopContentPane().add(new ErrorPane(exception.getErrorCode()));
}
}

}

and I overwrite (little bit of hacking with reflection) the UpdateManager of the ApplicationInstance as follows:

public ApplicationInstanceChild() {
super();
ReflectionUtil.setField(this, "updateManager", new ExceptionalUpdateManager(this));
}

This should solve the problem ! Every time a runtime exception is propagated, an error popup is shown with a description of the problem.

Wrestling with Spring Proxies

Today, I was wrestling with Spring 2 proxies for my pet project.
I wanted to switch back from AspectJ Transaction support to Spring AOP support and although it seemed easy, I stumbled on the following exception :

Caused by: org.springframework.aop.framework.AopConfigException: Couldn't generate CGLIB subclass of class [class hrutil.service.LoginApplicationService]: Common causes of this problem include using a final class or a non-visible class; nested exception is java.lang.IllegalArgumentException: Superclass has no null constructors but no arguments were given
Caused by: java.lang.IllegalArgumentException: Superclass has no null constructors but no arguments were given

The following code generated problems:

public class LoginApplicationService {
private UserRepository userRepository;
public LoginApplicationService(UserRepository userRepository) {
this.userRepository = userRepository;
}
...}

and

<bean id="loginApplicationService" class="hrutil.service.LoginApplicationService">
<constructor-arg ref="userRepository"/>
</bean>

It left me paralyzed for a moment, since I did define constructor arguments. Googling my problem finally brought the solution.

Spring can use two different techniques for creating proxies at runtime: CGLIB or JDK dynamic proxies. If the target class implements one or more interfaces, then Spring will create a JDK dynamic proxy that implements every interface. If the target class implements no interfaces, Spring will use CGLIB to create a new class on the fly that is a subclass ("extends") the target class. This leads to one important difference: a JDK dynamic proxy cannot be casted to the original target class because it's simply a dynamic proxy that happens to implement the same interface(s) as the target.

Another important difference (and the one that caused the exception) : CGLIB proxies cannot be used with constructor-arguments.

Thus, the problem can be solved in two ways:

1. Create interfaces for the services you want to proxy (never a bad habit and easily produced with your IDE's Extract Interface Refactoring).
2. Do not use Spring constructor arguments when CGLIB is selected.