Spring AOP top problem #1 - aspects are not applied

This post continues the theme started at Spring AOP top problem #2 - java.lang.ClassCastException: $Proxy7. I want to talk about the most popular (from my point of view) problem that spring users (especially the new one) encounter with spring AOP now.

I'm going to talk about 'self-calls' here, so if you have an experience with that feel free to skip the further material.

Please note that the spring reference describes the same problem - 8.6.1 Understanding AOP proxies. However, I found a lot of posts at the spring forums showing that people are unaware about it. So, I tried to explain it a bit wider/using another words.

Lets create a test-case that illustrates the problem. Suppose we're new to spring and just created a cool code that uses spring aop and works fine:

AopService.java

package com.spring.aop;

import org.springframework.stereotype.Component;

@Component
public class AopService {

    public void service() {
        System.out.println("AopService.service()");
    }

    public void anotherService() {
        System.out.println("AopService.anotherService()");
    }
}

TestAspect.java

package com.spring.aop;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Around;
import org.springframework.stereotype.Component;

@Component
@Aspect
public class TestAspect {

    @Around("execution(* com.spring.aop.AopService.*(..))")
    public Object advice(ProceedingJoinPoint joinPoint) throws Throwable {
        System.out.println("TestAspect.advice()");
        return joinPoint.proceed();
    }
}

spring-config.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="
  http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
  http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
  http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">

    <context:component-scan base-package="com.spring.aop"/>
    <aop:aspectj-autoproxy/>

</beans>

SpringStart.java

package com.spring;

import com.spring.aop.AopService;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class SpringStart {
    public static void main(String[] args) throws Exception {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("spring-config.xml");
        AopService service = context.getBeansOfType(AopService.class).values().iterator().next();
        service.service();
        service.anotherService();
    }
}

So, we see that there is a simple service class that just prints to stdout that its methods are called and simple aspect that intercepts all public method calls of that service and prints information about interception to the stdout as well. If we run SpringStart class we see the expected output - target service methods are intercepted by the aspect:

TestAspect.advice()
AopService.service()
TestAspect.advice()
AopService.anotherService()

Lets expand our service class a little:

AopService.java

package com.spring.aop;

import org.springframework.stereotype.Component;

@Component
public class AopService {

    public void service() {
        System.out.println("AopService.service()");
    }

    public void anotherService() {
        System.out.println("AopService.anotherService(). Calling AopService.service()...");
        service();
    }
}

We expect that the aspect is executed three times - service() and anotherService() calls from SpringStart.main() and service() call from AopService.anotherService(). However, if we run the example we can see that the aspect is executed only two times (for the calls issued from SpringStart.main()), i.e. service() call from AopService.anotherService() is not intercepted:

TestAspect.advice()
AopService.service()
TestAspect.advice()
AopService.anotherService(). Calling AopService.service()...
AopService.service()

As usual, problem root is tightly connected to The Law of Leaky Abstractions. I.e. we had particular expectations about aspect behavior but didn't realize that spring aop principles doesn't allow the expectations to occur.

The general idea is that spring AOP is proxy-based, i.e. it assumes that when the bean is used as a dependency and its method(s) should be advised by particular aspect(s) the container injects aspect-aware bean proxy instead of the bean itself. For example, returned proxy uses approximately the same algorithm as the one below:

public class AopServiceProxy {

    // Assuming that corresponding setters are introduced and the fields are defined.
    private TestAspect aspect;
    private AopService rawService;

    public void service() {
        aspect.advice();
        rawService.service();
    }

    public void anotherService() {
        aspect.advice();
        anotherService();
    }
}

I.e. the proxy is aspect-aware and it calls necessary aspect method before delegating the call to the 'raw' bean. However, last AopService implementation used to call service() from anotherService() - there is just no chance for the proxy to intercept that because the call is performed against 'this' reference, i.e. the call is performed on the 'rawBean' itself. That is the exact answer to why the aspect was not applied at that situation.

Now, when we understand the problem root we can talk about the ways to solve it. There are at least three ways:

• rewrite the code in order to avoid self-calls that should be advised by the aspects - rather inconvenient, especially if you work with the legacy code;


• replace self-calls with aspect-aware proxy calls, i.e. use the statement like ((AopService) AopContext.currentProxy()).service() instead of service() at the anotherService() - rather inconvenient too, requires additional proxy setup and totally couples the code to the spring;


• use aspectj weaving - that is my personal choice. Its idea is to inject aspect logic directly to the target class, i.e. remove the necessity to have all methods being proxied;

I'm going to create a small article that shows how to use various types of aspectj weaving with spring and that such approach completely eliminates the problem.