I'm seeing the following sequence of invocations during AS cluster classloader leak unit tests:

1. InvocationContextContainerImpl.createInvocationContext creates a new
LocalTxInvocationContext (lets call it #3011) and sets thread local
(icTL) to it.

2. InvocationContextContainerImpl.suspend() LocalTxInvocationContext
#3011 which clears the thread local reference.

3. We InvocationContextContainerImpl.resume() LocalTxInvocationContext
#3011 which sets the thread local reference.

4. We InvocationContextContainerImpl.suspend() LocalTxInvocationContext
#3011 which clears the thread local reference.

5. We InvocationContextContainerImpl.resume() LocalTxInvocationContext
#3011 which sets the thread local reference.

I don't see another suspend call, so LocalTxInvocationContext #3011 is
still referenced by the thread local InvocationContextContainerImpl.icTL which keeps the classloader in memory (the icTL reference is the only reference to the classloader).

Call stack showing where the LocalTxInvocationContext was created from http://pastie.org/1300157