Hi, I've been looking at http://jira.jboss.com/jira/browse/JBVFS-4?rc=1 to get it fixed and get acquainted with VFS in the process. I figure the current quick fix is called a hack because transient field vfsPath in AbstractVirtualFileHandler.java set through setPathName() only keeps it's value until it's serialized/deserialized. setPathName() should not exist at all, and AbstractVirtualFileHandler should contain enough information to properly lazy-init vfsPath. So the idea of a fix is (correct me if I'm wrong): a) get rid of setPathName() b) pass JARVFSContextUnitTestCase . testPathIsEmptryForJarEntryAsRoot c) don't break any tests First question, since VFS is such a central component, and I don't want to commit something that will break things for others - is the 'don't break any tests' a reasonable enough criteria for code 'commitability' or should I also at least make sure jboss5 default config runs with the new jboss-vfs.jar, or is there something else I should check as well? The second question, is there any VFS documentation? There's API class diagram on wiki, and there's some javadoc, but that's all I could find. vfsPath for example, what is its contract? Based on test cases, the contract seems to be: "vfsPath is a full path name relative to context root path" JarEntry as VFS root fails to stick to this contract, and that is the essence of this bug. For example, if full path name is: /dir1/jar2.jar!/org/jboss/someclass and context root path is /dir1/jar2.jar!/ then vfsPath is: org/jboss/someclass And code for it is very simple: fullPathName.substring(contextPath.length()); If naming scheme is consistently applied, then it's all very clean and simple. AbstractVirtualFileHandler currently has access to context root (context.getRootURI()), parent path name (parent.getPathName()), and name. In our case 'name' is not empty - it contains the name of the jar file. Question: is this expected and proper behaviour - that 'name' is not consistent with the naming scheme - that in this case it is not empty, but contains the name of the jar file? If this is proper behaviour, then maybe we need to provide extra information to AbstractVirtualFileHandler, because I don't know if we can properly generate pathName from existing information. If it's not proper behaviour, then we simply fix 'name' (all the code that passes bad name to file handler constructor) to conform to the contract and pathName will automatically get fixed. Feedback appreciated, Cheers, - marko View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135178#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...