Jason, thanks for the input. Both issues you have raised are already fixed in the trunk. :) Unfortunately, none of them issues are the cause of bug JBAOP-480. What is happening is that a thread is trying to generate a joinpoint class for a joinpoint whose info interceptor chain is null. Here is how this happens: in an if-statement, thread 1 checks that the info object of joinpoint A contains a non-empty interceptor chain; thread 1 is preempted by thread2; thread2 removes the last interceptor bound to joinpoint A, recreating a new info field for joinnpoint A with a null interceptor chain; thread1 resumes, generating code to intercept joinpoint A, without being aware that its info contains now a null interceptor chain. To avoid that, all I should do is to synchronize the thread on the joinpoint itself. This, added to some synchronization I have put on JoinPointInfo (I haven't commited this part since, alone, it is not a solution to anything), would do the trick. But the problem is which object should be picked for the synchronization on the joinpoint? If we generated only one joinpoint info during all the JBoss AOP execution, this info would be a no-brain choice. However, since a new info is created at every rebuildInterceptors execution, we have no such object. The interesting part is that I was already going to propose a change in this structure before Jason reported this concurrency isse :). My change would allow us to solve this problem easily, as well as bug JBAOP-380. Kabir, I'll let you know a more detailed picture of this new approach tomorrow morning. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099117#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...