It's org.jnp.server.Main and org.jboss.ha.jndi.DetachedHANamingService. Both take a couple threads from the pool and use them to handle incoming connections. They do nothing with the TCCL. That doesn't cause a problem with the real services, because 1) they are started by the main thread, so the TCCL they "leak" is (I think) the conf/jboss-service.xml classloader and 2) they hold onto their pool threads as long as they are running, i.e. pretty much the life of the server. The problem appears with NamingRestartUnitTestCase which deploys parallel naming services and restarts them numerous times. The testsuite problem should be fixed. I changed the naming-restart-beans.xml so it uses its own thread pool. It no longer leaks its classloader to the regular pool. anonymous wrote : the task that is using the new thread can't have the right TCCL if I understand correctly.anonymous wrote : | | | | Correct; it's indeterminate. The ThreadPoolExecutor creates a new thread when it needs one. The new thread picks up the TCCL of the thread that called BasicThreadPool.run(). That's probably the right one for that first task, but thereafter it isn't. So, yeah, a well written task will set the right TCCL and restore at the end. The naming services are not well written in this respect. But restoring the TCCL of a random first task does little good. Only the thread pool itself has the knowledge to restore a meaningful default TCCL (i.e. null or its own classloader). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127657#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...