Second invocation of Aspectj-adviced method in is ignored

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&g开发者_如何学Got;
</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.

---

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!