"flavia.rainone(a)jboss.com" wrote : "flavia.rainone(a)jboss.com" wrote : I was wondering is there is any way of identifying that specific type of scenario. If I could do that, I would generate the "bootstrap" CP only for "non-deployment" modules. This would avoid the problem in the scenario I described above without breaking testNonDeploymentModule. | | Actually, this is not what I want to do. This kind of fix would be useless, because, AFAIK, I could create the same ear scenario I described before using an beans.xml file. In that case, the "war" corresponding modules wouldn't be filtered out of JBossClDelegatingCPFactory.registerBootstrapLoaders, and the bug would occur again. I want to filter out the "bootstrap" modules that correspond to a submodule of the module whose CP is currently being created. In other words, in the scenario I described, where the war classLoader has the ear class loader as its domain (using an adapter), if the ear module is the one that was originally requested to JBossClDelegatingCPFactory, the war module is going to be skipped as a bootscrap cp. I think that that solves the bug. Is there an easy way of filtering out those scenarios? If not, I'm going to use the recursive structure of JBossClDelegatingCPFactory.registerBootstrapLoaders itself to abort the creation of a CP when its domain corresponds to a CP that is being created in an outer scope of the recursion. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266566#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...