1 Reply Latest reply on Mar 16, 2010 12:53 PM by Thomas Diesler

    Issues with vfs30 MountHandle

    Thomas Diesler Master



      I had a look at the MountHandle that was advertised in https://jira.jboss.org/jira/browse/JBVFS-147. Here some feedback.


      MountHandle is not part of VirtualFile. This forces clients to maintain an association of VirtualFile to MountHandle





      behaves differently depending on whether the VF has been mounted or not. Client code that needs stream access to the file's content would need to do some complicated processing like this


      if (isMountedSomehow(vfile))
         is = getStreamFromMountHandleSomehow(vfile);
         is = vfile.openStream();


      Also, consider this


      vfile1 = VFS.getChild("file:/somepath/somearchive.jar")
      mountHandle = mount(vfile1);
      vfile2 = VFS.getChild("file:/somepath/somearchive.jar")


      Both files behave quite differently WRT stream handling, etc.


      Consider the case of AbstractVFSArchiveStructureDeployer, which does an automount of the underlying file. Any structure deployer that comes after it cannot access the underlying file as a stream any more.


      IMHO there ought to be a layer that schields clients from changes in semantic behaviour caused by mounting. A client cannot know what happend to a VirtualFile before it accesses it methods. For example




      does vfile.getChild("META-INF/MANIFEST.MF") internally, which only works when the file had been mounted. A client would not know that nor is it obvious how to obtain the manifest from an unmounted file.


      Somehow I try to shield the OSGi layer from these semantic differences in





      which involves registries for VF/MH associactions. Additional methods like VirtualFile.getStreamURL() etc. The abstraction for VFS21 is more direct and cleaner in comparison. Again, IMHO a client of VFS30 should have access to an API which "always works" regardless of the internal details on VFS30 mounting.


      One obvious example is that my client code would need to do vfile access very differently depending on whether AbstractVFSArchiveStructureDeployer had automounted the vfile or not. This doesn't seem right especially if I need access to the "unmounted" bytes to pass on to 3rd party.

        • 1. Re: Issues with vfs30 MountHandle
          Thomas Diesler Master

          John says:


          When a URL points to a directory, you can not call InputStream.read and expect to get bytes back. Once the JAR is mounted in VFS it becomes a directory.

          If you need this to act as a File, then either:
          1.  Don't mount and use a JarFile
          2.  When mounting, retain the MountHandle and call getMountSource to get a handle to the actual file

          This needs to be handled correctly by the caller.


          Did you consider the case where I might not be the first who sees the file?

          In case of the structure deployer processing there might be an AbstractVFSArchiveStructureDeployer processing the vfile before my AbstractVFSStructureDeployer sees it. When I see the vfile it might already be mounted. In that case how do I get hold of the MountHandle?

          Generally, I believe that vfile.getChild(), vfile.openStream() and friends should behave in a deterministic way independent of what processing another component did previously.

          One possible way out of this might be to always provide access to the "virgin" source of the vfile.


          David says

          If you're not the first, then you do not have the right to access the archive, period. It's indistinguishable from a directory, and should be treated as such IMO.


          AFAICS, I cannot control whether I am the first (nor should I). In case I am not the first, the deployment may already have been transformed into a directory and I cannot access the archive any more.


          This seem to be a general issue of who comes fist + mounting prevents access to original archive.