Friday, February 4, 2011

Spring AOP - Changing target of a Proxy at runtime

I had a pretty strange usecase where i wanted to change the target object of the proxy and runtime. Spring makes it so simple to use.

My usecase was as follows

ApplicationContext ctx = new ClassPathXmlApplicationContext(
AccountDAO accountDao = (AccountDAO) ctx.getBean("accountDao");

IAccount account = accountDao.getById(123);

System.out.println("account" + account);


System.out.println("account" + account);

Is a property is change on the entity , i want to change the entity object itself , that is , in the above use two sysouts will print different objects.

The use case arose because i was using a cache(infinispan) which did not allow modifying POJOs outside a transaction scope.

I did achieve the same using the follwing

public class AccountDAO {

private Advisor advisor;

//This is get methods of the accountDao

public IAccount getById(long id) {
//creating new account - to mock database behavior
IAccount a = new Account(369, "suji");
//Using spring factory
ProxyFactory pf = new ProxyFactory();
//Using by own Target source to change the Target
pf.setTargetSource(new SwappableTargetSource(a));
//advisor which holds the advice and pointcut
return (IAccount) pf.getProxy();

public void setAdvisor(Advisor advisor) {
this.advisor = advisor;


My advice class

public class SwappableBeforeAdvice implements MethodBeforeAdvice {

public void before(Method method, Object[] args, Object target)
throws Throwable {
System.out.println("Before advice called");

if (!((IAccount) target).isWritable()) {

//Changing the target source based on specific business condition
((SwappableTargetSource) ((Advised) AopContext.currentProxy())
.getTargetSource()).swap(new Account(56, "dan"));


My custom target source

public class SwappableTargetSource implements TargetSource {

private Object target;

public SwappableTargetSource(Object initialTarget) { = initialTarget;

public synchronized Class<?> getTargetClass() {

public final boolean isStatic() {
return false;

public synchronized Object getTarget() {

public void releaseTarget(Object target) {
// nothing to do

public synchronized void swap(Object newTarget)
throws IllegalArgumentException { = newTarget;

public boolean equals(Object other) {
return (this == other || (other instanceof SwappableTargetSource &&
.equals(((SwappableTargetSource) other).target)));

public int hashCode() {
return SwappableTargetSource.class.hashCode();

public String toString() {
return "SwappableTargetSource for target: " +;


These are the spring xml configuration.

<bean id="accountDao" class="com.test.dao.account.AccountDAO">
<property name="advisor" ref="settersAdvisor" />

<bean id="swapableBeforeAdvice" class="com.test.framework.SwappableBeforeAdvice"/>

This is the advice which advise all setter methods on the bean

<bean id="settersAdvisor"
<property name="advice">
<ref local="swapableBeforeAdvice" />
<property name="patterns">

Thanks to this post in spring forum which helped me do this.

Unit test framework with Liquibase+HsqlDb+Spring transactions

When looking at options for testing DAO classes I came up with a framework using the following

1. Liquibase - For maintaing data/schema scripts

2. HSQLDB - Inmemory database for test cases

3. Spring transactions - For maintaining clean state between two test cases which make DB updates i .e all data changes made by the test cases will be rolled back by the end of the test case.

I am using spring beans to initialize all the above. I will explain each of them in detail.

1. Initializing the HSQLDB

location="classpath*" />

<bean id="hsqlDataSource" class="org.apache.commons.dbcp.BasicDataSource"
<property name="driverClassName" value="${database.driverClassName}">
<property name="url" value="${database.url}">
<property name="username" value="${database.username}">
<!-- <property name="password" value="${jdbc.password}"> -->

All the values will be picked up from the file mentioned in the classpath.

2. Setting up Liquibase

I am using the following method to initialize Liquibase

public class TestFramework {

private DataSource dataSource;

public void initializeLiquiBase(String changeLogFile) throws Exception {
Connection conn = dataSource.getConnection();
Liquibase liquibase = new Liquibase(changeLogFile,
new ClassLoaderResourceAccessor(), new HsqlConnection(conn));
// Uncomment the following line when testing with mysql database
* Liquibase liquibase = new Liquibase(changeLogFile, new
* ClassLoaderResourceAccessor(), new JdbcConnection(conn));


public void setDataSource(DataSource dataSource) {
this.dataSource = dataSource;


Corresponding spring configuration.

<bean id="testFramework" class="com.mycompany.framework.unittest.TestFramework">
<property name="dataSource" ref="hsqlDataSource">

The changeLogFile will be provided by the user of the frame work , which i will explain shortly.

3. Setting up Spring transactions.

<bean id="transactionManager"
<property name="dataSource" ref="hsqlDataSource">

<tx:annotation-driven manager="transactionManager">

These are the only classes/configuration present in my framework

The maven dependencies required are as follows


Now let me explain how the framework will be used by the classes testing the framework

A typical test class for DAO will be as follows

@ContextConfiguration(locations = {
"classpath*:/META-INF/spring/test-spring-jdbc-module-context.xml" })
public class TestAccountDAOSpringJdbc {

private TestFramework testFramework;

private AccountDAOSpringJdbc accountDao;

public void setUpBeforeClass() throws Exception {
System.out.println("Setup before class called");

public void testSaveUpdate() throws Exception {
// Create a new Account
Account account = accountDao.get(1);



The important thing to note here are

1. Initializing the framework beans - which contains HSQLDB and spring transaction initialization.

2. Initializing the test framework with liquibase scripts

This ensure that the database tables are created and test data is inserted before test cases run.


3. Using @Transactional annotation before test cases which updates the Database . This ensures that test cases do not commit anything into DB and all test cases can be independent of each other.

With some infrastructure setup like this , writing test cases for DAO become very easy.

Friday, January 21, 2011


Bamboo is another available tool for setting Continuous Integration in your environment. Its one of the simplest tools i have come across for building a continuous integration system.

The website shows a 10 minute tutorial which helps in setting up and starting the continuous integration server. The configuration options with this tool are very simple and helps in setting up the environment through the user interface available in this tool.

It has easy integration with build tools like Maven, Ant etc.


I have been using ant for a pretty long time and i was very comfortable with the flexibility it gives , until i started using Maven. Its almost been a month since i have started using maven , and i feel i will never go back to ant.

Maven works on the principle on "Convention over Configuration" .

Basic convention is each module builds a single artifact and there is a pom file associated with each module which describes all the dependencies required by the module and the properties of the module. The pom file when run can help you do a lot of things like

Compile the code.
Build the Jar
Run the test cases.
Build Java Docs ...etc and many more

Each of the above tasks belong to a particular phase in the Maven build cycle. The best things to use Maven is with a IDE like Eclipse or STS which has complete support for maven.

After i thought about writing the basics of Maven , i came across this blog from spring source which in details explains about the basics of Maven which should be a good starting point.

Maven comes in with easy integration for build tools like Bamboo, Hudson and Cruisecontrol.

Once you start using Maven managing the modules. its version and its dependencies becomes a very simple task.

Free Domain Names @!