Since 5.1.0.Beta1, there is a new way to define thread pools, thread factories, and other thread-related stuff. If you've got a service (especially a POJO-ized service) that is deployed in the AS, I recommend that you have a look at migrating your deployment to use this new mechanism. The project is called JBoss Threads, and there's a bug tracker for it here: https://jira.jboss.org/jira/secure/project/ViewProject.jspa?pid=12310786 The idea is that you can declare a thread pool in your service deployment descriptor, and then you can inject this thread pool as an Executor into a managed bean, sort of like this example jboss-beans.xml file: <deployment xmlns="urn:jboss:bean-deployer:2.0"> <threads xmlns="urn:jboss:threads:1.0"> <thread-group name="MyThreadGroup" group-name="mine"/> <thread-factory name="MyThreadFactory" group="MyThreadGroup" thread-name-pattern="my-pool%f-%t"/> <thread-pool-executor name="MyExecutor" thread-factory="MyThreadFactory" allow-core-timeout="true" queue-length="50"> <core-pool-size count="5"/> <max-pool-size count="10" per-cpu="2"/> <keepalive-time time="10" unit="seconds"/> <reject-policy name="block"/> </thread-pool-executor> </threads> <bean class="your.bean.Class"> <property name="executor"> <inject bean="MyExecutor"/> </property> </bean> </deployment> This example makes a thread pool executor that has no threads until tasks are submitted, and keeps idle threads around for 10 seconds before cleaning them up. The pool will not grow larger than 10 threads plus 2 threads per detected CPU. If your component already expects an injected Executor, then this should be a trivial change to make. This implementation does not implement the older ThreadPool-related interfaces from jboss-common-core. My personal inclination is to leave it off and migrate to a fully Executor-based system. Things that require functionality only provided by the older API could perhaps still be accomodated by some kind of wrapper mechanism, if necessary. There are some todo items, like developing a mechanism to automatically propagate relevant contextual information from the executing thread to the executor thread (including but not limited to the thread context class loader). I'd like to develop a more generic mechanism though (the idea being that the average user can inject an Executor to use from any old deployment, and everything that can just magically work, will). Ideas are welcome. :-) Also, there is no JMX management view yet (this is a TODO for CR1). The advantage to this model is that implementation details (class name, property names) of the thread pool are no longer specified in the deployment descriptor, which means that the class can change under certain circumstances (in fact, the class is already substituted when there are parameter combinations which are not supported by the standard ThreadPoolExecutor). This is a model I hope that we can continue to move towards. - DML