JBoss development, A new message was posted in the thread "Issues with vfs30 MountHandle": http://community.jboss.org/message/531973#531973 Author : Thomas Diesler Profile : http://community.jboss.org/people/thomas.diesler@jboss.com Message: -------------------------------------------------------------- Folks,   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   VirtualFile.isFile() VirtualFile.openStream()   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); } else {    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   VFSUtils.getManifest(vfile)   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   http://fisheye.jboss.org/browse/JBossOSGi/projects/vfs/trunk/vfs30/src/ma... http://fisheye.jboss.org/browse/JBossOSGi/projects/vfs/trunk/vfs30/src/ma...   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 dependeing 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. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/531973#531973