One usecase that came up is to able to explicitly create a top level classloader for a subdeployment rather than an isolated classloader hanging off the main deployment classloader. This could for example be signaled by the user explicitly specifying the classloader domain. We currently ignore the user specified domain when it is a subdeployment, since we have to construct a synthetic domain with the main deployment's classloader as parent. In this case, instead of constructing a synthetic domain we would just respect the user's decision and make the subdeployment classloader a top level classloader. e.g. top-level.jar/sub-deployment.jar/META-INF/jboss-classloading.xml | <classloading domain="MyDomain" xmlns="urn:jboss:classloading:1.0" | import-all="true" export-all="ALL"> | </classloading> | This will currently create a classloader for top-level.jar (minus the classes in sub-deployment.jar) in the default domain then construct a synthetic "top-level.jar/sub-deployment.jar" domain. DefaultDomain <- top-level.jar <- synthetic domain <- sub-deployment.jar With the proposed change (explicit domain) it would instead look like this: DefaultDomain <- top-level.jar MyDomain <- sub-deployment.jar (now a top level classloader) NOTE: Ironically this would actually take us back to allowing something simiar to early jboss-3.0.x classloading rules where every subdeployment had its own classloader ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153316#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...