[ https://jira.jboss.org/jira/browse/JBVFS-147?page=com.atlassian.jira.plug... ] John Bailey edited comment on JBVFS-147 at 3/9/10 9:45 AM: ----------------------------------------------------------- As mentioned in JBVFS-142, this will not work for a mounted JAR. Once a JAR is mounted into VFS, it becomes a directory in VFS. So you will not be able to read it as a conventional InputStream. You will actually be getting a VirtualJarInputStream, which functions as a JarInputStream, so you would need to cast the input stream call getNextEntry for each entry. For the code you have written in the description, you could make it work by just using a file: URL in place of the vfs: ULR (with the VFS trunk). This will delegate to the real filesytem, and you should be able to read the JAR in as a standard file. was (Author: johnbailey): As mentioned in JBVFS-142, this will not work for a mounted JAR. Once a JAR is mounted into VFS, it becomes a directory in VFS. So the you will not be read it will a conventional InputStream. You will actually be getting a VirtualJarInputStream, which functions as a JarInputStream, so you would need to cast the input stream call getNextEntry for each entry. For the code you have written in the description, you could make it work by just using a file: URL in place of the vfs: ULR. This will delegate to the real filesytem, and you should be able to read the JAR in as a standard file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBVFS-147?page=com.atlassian.jira.plug... ] David Lloyd commented on JBVFS-147: ----------------------------------- If their bundle deployer wants to do the JAR handling, then don't mount it and it'll work fine. You can basically choose. Either mount it and treat it like a directory, or don't mount it and treat it like a file. You can't do both. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBVFS-147?page=com.atlassian.jira.plug... ] John Bailey commented on JBVFS-147: ----------------------------------- VFS was update to provide a caller invoking a mount operation access to the source file used for mounting. The mount source is preferable to the getting the physicalFile before mounting as it actually returns the copy if created at mount time. Most archive mounts will create a copy of the archive before opening the zip to avoid file locking issues. So it is always better to use the mount source if you need access to the file. Below is an example for getting access to the mount source. ------ VirtualFile jarFile = VFS.getChild("/path/to/archive.jar"); MountHandle handle = VFS.mountZip(jarFile, jarFile, tempFileProvider); File mountSource = handle.getMountSource(); // Do some stuff with either the VirtualFile or the source File VFSUtils.safeClose(handle); ------ Note, the Automounter does not return MountHandles. This is by design. Use of the Automounter should be restricted to situations where there is no clear way to hold onto the MountHandle for later cleanup. So if you need access to the mount source, you will need to perform the VFS mount call without the Automounter, and preform the cleanup when finished with it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBVFS-147?page=com.atlassian.jira.plug... ] John Bailey resolved JBVFS-147. ------------------------------- Resolution: Won't Fix This needs to be handled correctly by the caller. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBVFS-147?page=com.atlassian.jira.plug... ] David Lloyd commented on JBVFS-147: ----------------------------------- 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBVFS-147?page=com.atlassian.jira.plug... ] Thomas Diesler updated JBVFS-147: --------------------------------- JBoss Forum Reference: http://community.jboss.org/thread/149439?tstart=0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBVFS-147?page=com.atlassian.jira.plug... ] Thomas Diesler updated JBVFS-147: --------------------------------- Fix Version/s: 3.0.0.CR6 (was: 3.0.0.CR5) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira