Cause for reopening JBDEPLOY-59. I commited deployers/build/pom.xml to use the latest Classloading snapshot. The ManifestClassLoaderUnitTestCase is failing due to ordering issue. With the new Classloading code that tries to resolve ClassLoadingSpace, this piece causes child modules to declare its vfs roots before parent modules. org.jboss.classloading.spi.dependency.Domain: | // Skip the classloader space checking when it is import all | if (module.isImportAll() == false) | { | ClassLoadingSpace space = new ClassLoadingSpace(); | space.join(module); // starting here! | } | In the test top-level.jar is import-all == true, where top-levelsub.jar is import-all == false. 1) space.join(module) calls module.determinePackageNames 2) module.getCapabilities calls module.determineCapabilities 3) module.determineCapabilities in VFSDeploymentClassLoaderPolicyModule uses determineVFSRoots And since parent hasn't been yet examined, this code is never called | Set<VirtualFile> parentClassPath = parent.getAttachment(VFS_CLASS_PATH, Set.class); | if (parentClassPath != null) | { | if (log.isTraceEnabled()) | { | for (VirtualFile parentFile : parentClassPath) | { | if (classPath.contains(parentFile)) | log.trace(unit + " weeding duplicate entry " + parentFile + " from classpath already in parent " + parent); | } | } | classPath.removeAll(parentClassPath); | } | leaving the sub's classpath intact. Hence it loads class from it's own classloader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165497#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...