Home/ Questions/Q 6564893
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T14:01:34+00:00

I am in the process of adding some AspectJ advices in my Spring -based

  • 0

I am in the process of adding some AspectJ advices in my Spring-based Java project. When I run an intercepted method once, it all works fine (i.e., the advice is executed). However, the next invocation of the very same method does not go through the proxy anymore.

This is my test code:

@Test
public void testFooOperationIsAdviced() throws Exception {
    TestController testController = appContext.getBean("testController");
    testController.foo();
    testController.foo();
}

Here’s the foo() method:

@Protect()
public void foo() {
    System.err.println("foo!")
}

And this is the relevant part in my Spring configuration:

<aop:aspectj-autoproxy />
<bean name="myAdvice" class="mypackage.MyAdvice"/>

<bean id="testController" class="mypackage.MyTestControllerImpl" />

<aop:config>
    <aop:aspect id="protectAspect" ref="myAdvice">
        <aop:pointcut id="annotatedController" expression="execution(public * mypackage.*+.*(..)) and @annotation(protect)" />
        <aop:around pointcut-ref="annotatedController" method="applyProtectionRules" arg-names="protect"/>
    </aop:aspect>
</aop:config>

The aspect is currently just doing System.err.println("advice") and pp.proceed().

So, if we execute the test above, you’d expect

advice
foo!
advice
foo!

However, what I get is:

advice
foo!

The second invocation never gets to the advice! And, what is worse, the target method is not even executed.

Do you have any clue as to why this happens?

Note 1: To make things worse: sometimes, when I execute with the debugger and go step by step, it does work normally. No kidding…

Note 2: If there are typos in the config, they are just typos, since I adapted the original code to make it simpler. Take into account that the aspect does work for the first invocation.

Note 3: I do want to stick to Spring. I can’t have the pointcuts hardcoded in the Java code, since I want the library user to provide their own, and the only way I can think of is let them define the aop:config block.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Looking at the 2-kilometer-long stack trace, I saw a CachingInterceptor… That’s the solution to the mystery: our custom caching mechanism, based on a Spring method interceptor, was doing the trick. It has a timeout of 120 seconds, and that’s why the execution seemed fine when I used the debugger.

    I won’t close my (admittedly dumb) question in case it helps others. A bit of perspective and thinking out of the box would’ve helped!

    • 0