Concerning the "clean redeploy" of classes, instead of relying on facing hotswap behaviour or similar, why not use a simpler approach where we would load the NEW classes in a new Classloading tree and start routing new requests to that classes tree once it has been properly loaded? The trick is to make sure that the SAME "containers" and services are able to work on multiple classes trees (and, for example, keep a single version of a cache, or a lock table, of a transaction table, etc. => services and containers would rely on specific ID, not on specific class instances) That way, if you have a long running requests being processed, this request can continue in parallel with new requests. The old request would keep using the old classes definition while new requests could use the new class definitions. That could also speed up app re-deployment A LOT: there wouldn't be this huge gap anymore between the undeploy of version 1 and the total redeploy of version 2: instead, any requests would be able to keep using version 1 while we fully load version 2 and at that time, we can do a micro-switch that would route any incomnig request to the new class tree. This could certainly be easily handled by using the per-container/per-request METADATA i.e. the class tree to use would be specified in the METADATA and used dynamically at runtime by the containers/services. That means we could also support, in a more "production" kind of environment, stable "switch of releases" i.e. JBoss ON could distribute a new version of an application to 50 nodes of a cluster, PREPARE the application by loading it in a new class tree and, once all nodes have successfuly loaded the new tree, you atomically re-route all new requests to this new app => standby mode for pre-loaded apps. This scenario is probably slightly more complex as it would probaly require a change in metadata, hence is possibly a different scenario. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988841#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...