One thing showing up with the addition of the hot deployment scanner is a lack of a class loading model from Deployer/MainDeployer level. We fist saw this when needing to add a hack to the ProfileServiceBootstrap that pulled the first DeploymentContext class loader from the bootstrap deployment phase. It showed up in the shutdown thread not knowing how to set the correct context class loader, and again with the hot deployment scanner not knowing this. Here is the current problem. We have a bootstrap URLClassLoader that includes the static mc and related jars. The is the default tcl. It has no access to the profile jars (server/default/lib for example). When we bootstrap the profile, the conf/bootstrap-beans.xml is loaded using the bootstrap class loader. We then add the legacy conf/jboss-service.xml which creates a ULR(unified loader repository) based on the profile static jars (server/default/lib/* for example) and there is an expectation that this URL will be the parent of subsequent deployment phases (deployers, deploy content). However, we don't have a class loading model/api that allows the caller of MainDeployer.process to establish a valid tcl, nor does the current DeploymentUnit.getClassLoader() allow the MainDeployer dispatch of deploy under the correct class loader. does The problem is that DeploymentUnit.getClassLoader() does not return a class loader until a deployer in the chain has created it. The deployer runs late in the process and prior deployers looking to the classpath for resources, classes imported from the bootstrap phase don't have valid class loader from either the tcl or DeploymentUnit apis. I think we need to look at how we are going to generalize the implicit ULR peer class loading model to an osgi bundle type of model and make that an explicit aspect of the deployment apis. At the start of each deployment phase we need to be able to establish a bootstrap bundle class loader that allows access to the structural classpath for local resources, as well as ties into imported parent/peer class loaders for shared resources/classes from previous deployment phases. The number of bundle class loaders would expand to include local classes and exported classes as the deployment process moves to the current class loader deployer(s). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028960#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...