[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: JarEntry as VFS root does not return empty vfspath

[scott.stark@jboss.org]

"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#4135181

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135181