Discussion of solution to http://jira.jboss.org/jira/browse/JBCOMMON-41[/url] . For background on the problem see [url]http://www.jboss.com/index.html?module=bb&op=viewtopic&t=129122 . I intend to solve this by having the BasicThreadPool set an appropriate TCCL on the pool thread: 1) in the ThreadPoolFactory, just after creating the thread. 2) when a thread is returned from a task, by subclassing ThreadPoolExecutor and overriding afterExecute(). What TCCL gets set will be configurable by an injectable policy: | package org.jboss.util.loading; | | public interface ClassLoaderSource { | | /** | * Returns the classloader provided by this object; may return null. | */ | ClassLoader getClassLoader(); | | } | If no ClassLoaderSource is injected, the TCCL will be set to null. In common-core I'll add a basic SimpleClassLoaderSource which simply returns getClass().getClassLoader(). In the AS, that would return the classloader that loads $JBOSS_HOME/lib. Somewhere else, (AS server module?) I'll add another impl that exposes a start() and stop() method. In start it will cache a weak ref to the current TCCL, and will thereafter return that. This could be injected into the jboss.system:service=ThreadPool pool; it will return the classloader in effect when conf/jboss-service.xml is deployed. That seems like a reasonable default for that service, or at least is likely closest to the "typical" behavior of the current thread pool. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128107#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...