Try it. And catch it, finally.

Aspect-oriented programming (AOP) is a programming paradigm that increases modularity by enabling improved separation of concerns. While object oriented programming paradigms support encapsulation of concerns, some concerns defy these forms of implementation and are called crosscutting concerns because they “cut across” multiple abstractions in a program. Logging is a common example of a crosscutting concern because a logging strategy necessarily affects every single logged part of the system.

For introducing AspectJ based AOP within the well-known Spring Framework, we just need a few lines of Spring Configuration

<!-- Activating AspectJ in Spring Config -->
<aop:aspectj-autoproxy/>

<!-- Configuring the Bean declaring the Aspect -->
<bean id="testAspect" class="spring.demo.TestAspect"/>

<!-- Some Test Bean to demonstrate the Aspect Execution -->
<bean id="test" class="spring.demo.Test"/>

plus: the Class declaring the Aspect, of course

@Aspect
public class TestAspect {

    @Pointcut("execution(* *(..))")
    public void methodExecution() {}

    @Around("spring.demo.AspectJTest.TestAspect.methodExecution()")
    public Object doTrace(ProceedingJoinPoint pjp) throws Throwable {
        Log log = LogFactory.getLog(pjp.getSignature().getDeclaringType());
        Object retVal;
        log.info("Starting method " + pjp.getSignature().toLongString());
        retVal = pjp.proceed();
        log.info("Ending method " + pjp.getSignature().toLongString());
        log.info("Method returned " + retVal);
        return retVal;
    }

}

As this Aspect triggers the @Around method on every method execution invoking the method boolean doSomething(boolean) on our Test Class

public class Test {
    public boolean doSomething(boolean param) {
        LogFactory.getLog(getClass()).info("About to return " + param);
        return param;
    }
}

will lead to something like the following sample output proving the execution of the TestAspect.doTrace(...) method:

Starting method public boolean spring.demo.Test.doSomething(boolean)
About to return true
Ending method public boolean spring.demo.Test.doSomething(boolean)
Method returned true

which is nice, actually. The Full Spring Guide on this can be found here

In my last project I ran into an “actually” quite obvious trouble I want to resolve properly once and for all times, because I expect it to be a regular requirement when working with something like JPA/Hibernate persistence layer and something like the Spring Framework Bean Instantiation mechanism.

When I persist some JPA mapped Entity into my database, I’d later on very much like to be able to recover it exactly in the state when it was persisted. This is what persistence is all about anyway, isn’t it? It is, but troubles arise when this persisted Entity originally was instantiated based on some Spring Prototype Bean Configuration. Typically, Parts of the Properties of such a prepopulated Beans are just for Configuration Purposes and to persist those Properties to the Database is either obsolete and causing a lot of redundant and performance burdening data (in case of e.g. simple configuration values or beans), but can also turn out to be difficult or impossible to achieve in case the injected Data (e.g. some Configuration carrying Singleton Bean) is just not made to be persistent.

However, later on, when recovering such an Entity from the Database it will have lost all it (non-persistent) configuration data. Of course: JPA/Hibernate constructs the Java Objects via the Default Constructor of the Class and populates it with the Property Values persisted in the Database. That’s it, basically. The solution for my issue should be easy and some instructions and/or even ready code should be obtainable via the Internet: I just have to “teach” Hibernate to construct the Java Objects derived as Database Entities not via the default Class Constructur but via the Spring Bean Instantiation. I “just” have to do some research about this…

Once having this in place, I expect such an approach to turn out to make very good sense for almost all persistent Entities, also for the simple cases, because it allows

• To externalize the configuration of transient-only Property values with default (prepopulated) values becoming persistent later on and to have all this transparent in one place within the Spring Prototype Bean Configuration.
• Domain specific Object Models to carry some (e.g. DAO aware) lookup or logic methods in case applicable and useful.

I’m eager to see it working soon!

(This post is part of my thoughts about A portfolio for Enterprise Web Applications)