"alesj" wrote : | Perhaps we should add another (hard keeping track of all) flag to VFS, | that would also ignore everything - as did the old code. A single flag in VFS would make it hard to control. i.e. it might be ok for the deployers to ignore the error in the classpath but for other uses it would not be ok. Also the VFS would have to cache/remember the brokeness since there is no way to "weed out" the problem during startup. Otherwise it would continually try to copy the jar and get the same error. I personally don't think it is even ok for the deployers/classloader to ignore the error and the example Luc provides is correctly rejected. i.e. the real solution is to fix the deployment The reason I think it needs addressing is because we never really used to look at nested deployments in server/default/lib (i.e. those specifed on a -service.xml classpath). The reason we are doing so now is because the PackageVisitor is triggering the VFS to unpack the archive when it is scanning for the packages in the jars. Maybe a simpler (but less inclusive fix) would be to have the PackageVisitor ignore archives in its VFS visit()? e.g. | public boolean accepts(VirtualFile file) | { | // This is our current root | if (file.equals(root)) | return true; | | + // Don't go into nested archives | + if (file.isArchive()) | + return false; | | // Some other root, it will be handled later | for (VirtualFile other : roots) | { | if (file.equals(other)) | return false; | } | // Is this an excluded roots? | if (excludedRoots != null) | { | for (VirtualFile other : excludedRoots) | { | if (file.equals(other)) | return false; | } | } | | // Ok | return true; | } | But I'm not sure if that is too late in terms of the archive getting unpacked? It would certainly be an optimization in terms of the scanning anyway. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4182193#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...