The handling of InvocationContext will leak JBC's classloader. An InvocationContext gets stored in a ThreadLocal and doesn't get cleared. This is by design to avoid creating a new InvocationContext for each request, but it will have the effect of leaking the JBC classloader to whatever threads call into JBC. Note that the fact that CacheImpl.invocationContextContainer is an instance field will not prevent the leak. When the CacheImpl is gc'd, the invocationContextContainer ThreadLocal will be gc'd as well. However, for each thread that invoked on the cache there will still be a ThreadLocal.ThreadLocalMap.Entry whose value field is a strong ref to the InvocationContext. If a particular thread's ThreadLocalMap happens to do some cleanup work (i.e. a rehash) it will detect that that ThreadLocal has been gc'd and expunge the Entry, but to allow the classloader to be gc'ed all such threads would have to do that, which is unlikely. Solving this will be a pain, since clearing the ThreadLocal after each request will likely break a number of subtle things where code calls back into the cache. For example, Notifier would probably have to be changed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052259#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...