"mstruk" wrote : | 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? | | "mstruk" wrote : | | 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. | | | javadocs and tests are all that exists currently. | | "mstruk" wrote : | | 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" | | | Correct. | | "mstruk" wrote : | | JarEntry as VFS root fails to stick to this contract, and that is the essence of this bug. | | | | We have a number of issues with relying on the jdk jar classes, the JarEntry naming, jar: urls not supporting nested jars, JarFile not being serializable, JarFile requiring a java.io.File are the issue off of the top of my head. | | Not using the JarEntry name, removing AbstractVirtualFileHandler.setFileName, and fixing the existing usage of setFileName may work, but I suspect we need to redo how we handle jars to not rely on JarFile. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135181#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...