I wrote an alternative implementation of jar handling - from scratch in order to simplify and reduce the amount of code, and specifically to address the problems I kept running into when trying to fix JBVFS-4. I currently have what appears to be a fully working jar handling implementation, that exists in parallel to vfsjar - I named it vfszip. It works with jboss trunk, it does away with issues I was working on in vfsjar, and has no problems with file locks on windows - undeployment and redeployment work as they should. I don't think it's production ready but it may be getting close. Some things still need to be finalized - temp files for inner jars, serialization, priviliged blocks, and maybe other things I don't see yet. Performance-wise it is comparable to vfsjar, I did not do any memory profiling yet. Also archive file closing / reopening is a little bit too aggressive at the moment, so performance can still be improved by a few percent. Some details about my implementation ... I made no change to VFS API - I did make some additions and changes in abstract context and handler classes that don't affect other vfs context implementations. I changed FileSystemContext to use vfszip impl instead of JarHandler - it could be made configurable through system properties. I centralized all the logic in one place - in ZipEntryVFSContext, so it's easy to control access to resources (files). This way handlers are little more than proxies to a context. I tightly coupled ZipEntryHandler to ZipEntryVFSContext. I think it's not such a good idea to pass FileSystemContext to a JarHandler for example - significantly limiting how the two can interact. My ZipEntryHandler presupposes it is created through ZipEntryContext, so it works with ZipEntryContext directly and can interface with it in implementation specific ways. I remodeled the code in such a way that the same code can be used to handle inner jars and outer jars by mounting ZipEntryVFSContext into another ZipEntryVFSContext - I introduced a mounting mechanism using ReferenceHandler and a little extra code in abstract classes. This way a jar file inside FileSystemContext is handled by mounting a ZipEntryVFSContext. The code is more modular and more contained. JBVFS-4 is a natural non-issue in this alternative implementation. Handling of inner jars of arbitrary depth is automatic. When file locking issue came to my attention I was able to fix it in a few hours with this implementation. Due to centralized access to jar files the issue was trivial to fix. My implementation makes no use of jar:file: URLs. My handler does not extend AbstractURLHandler - I don't use URL for getLastModified(), getSize(), openStream(). My implementation controls access to JarFile centrally inside context and opens and closes it as necessary. For URLs, vfsURLs I always generate vfszip: url schema so any URL access goes through VirtualFileURLConnection and through my context again. The code is in svn: https://svn.jboss.org/repos/jbossas/projects/vfs/branches/jar-alter-work If anyone is interested, give it a try, take a look at the code, tell me what you think, what's missing, what's not working properly ... I'll be glad to answer any questions. Cheers :) - marko View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147669#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...