[VFS] canCreateFileSystem("directory.jar/")

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[VFS] canCreateFileSystem("directory.jar/")

Bernd Eckenfels
Hello,

I want to use the VFSClassLoader on JAR files and Directories (to provide  
resources). My problem is, that some directories are exploded archives and  
have a name with a .jar extension.

The addFileObjects() of the VFSClassLoader uses canCreateFileSystem() to  
detect, if for a given file is a overlay which can read its content.  
However this method uses FileTypeMap#getScheme(file) which does look at  
the mimetype and extension of the file name, but not if it is actually a  
file.

I think VFSClassLoader can check for hasContent() but I think that the  
solution should actually somewhere in canCreateFileSystem() as I could  
image there is a overlay filesystem which maps a directory into a  
filesystem (think .git).

Any ideas? Should I provide a patch for VFSClassLoader only to start with?

Gruss
Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] canCreateFileSystem("directory.jar/")

Bernd Eckenfels
Hello,

I have filed this Bug report and also provided a fixed version (on Github):

https://issues.apache.org/jira/browse/VFS-490
https://github.com/ecki/seeburger-vfs2/blob/master/vfs2provider-jdbctable/src/main/java/com/seeburger/vfs2/util/VFSClassLoader.java#L152

Greetings
Bernd

Am 16.08.2013, 23:31 Uhr, schrieb Bernd Eckenfels <[hidden email]>:

> I want to use the VFSClassLoader on JAR files and Directories (to  
> provide resources). My problem is, that some directories are exploded  
> archives and have a name with a .jar extension.
>
> The addFileObjects() of the VFSClassLoader uses canCreateFileSystem() to  
> detect, if for a given file is a overlay which can read its content.  
> However this method uses FileTypeMap#getScheme(file) which does look at  
> the mimetype and extension of the file name, but not if it is actually a  
> file.
>
> I think VFSClassLoader can check for hasContent() but I think that the  
> solution should actually somewhere in canCreateFileSystem() as I could  
> image there is a overlay filesystem which maps a directory into a  
> filesystem (think .git).
>
> Any ideas? Should I provide a patch for VFSClassLoader only to start  
> with?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[VFS-490] Re: canCreateFileSystem("directory.jar/")

Bernd Eckenfels
In reply to this post by Bernd Eckenfels
Hello,

a while back I started this discussion on retrieving schema from file  
names and the relation to VFSClassLoader (the reason beeing I cannot add a  
directory "scripts.jar/" to the VFSClassLoader because it always tries to  
overlay the JAR Filesystem.

I have opened a JIRA for this, and also sent a pull request with a  
suggested fix:

https://issues.apache.org/jira/browse/VFS-490

https://github.com/apache/commons-vfs/pull/2


Gary had a look at it and asked me for Unit t ests, and here is my problem  
with it. I have added the following two tests to the existing TestCase,  
and wanted to add them to the pull request, but I could not make them work  
entirely. If I manually only run them on the local provider they pass, but  
otherwise all kind of internal errors turn up which I guess are related to  
missing/changed state of the FileSystemManager (like Missing replicator,  
missing JAR provider).

I must admit I dont really understand the JUnit scenario with those  
provider specific configurations of test suites, so it is hard for me to  
fix. Maybe somebody could have a look into it?

First I added a file  
src/test/resources/test-data/directory.jar/insidedirectory.txt, then I  
added the following tests:

     /**
      * Make sure directories are never interpreted as JAR files (fixes  
VFS-490)
      */
     public void testOpenJarDirectory() throws Exception
     {
         final DefaultFileSystemManager manager = createManager();
         if (!manager.hasProvider("jar"))
         {
             manager.addProvider("jar", new JarFileProvider());
             manager.addExtensionMap("jar", "jar");
         }

         FileObject file = getBaseFolder().resolveFile("directory.jar");
         assertTrue(file.isFolder());
         assertFalse(manager.canCreateFileSystem(file)); // VFS-490

         final VFSClassLoader loader = new VFSClassLoader(file, manager);
         final URL resource = loader.getResource("insidedirectory.txt");
         assertNotNull(resource);
     }

     /**
      * Test adding JAR files to classpath.
      */
     public void testOpenJarFile() throws Exception
     {
         final DefaultFileSystemManager manager = createManager();
         if (!manager.hasProvider("jar"))
         {
             manager.addProvider("jar", new JarFileProvider());
             manager.addExtensionMap("jar", "jar");
             //manager.setCacheStrategy(CacheStrategy.ON_RESOLVE);
         }

         FileObject file = getBaseFolder().resolveFile("test.jar");
         assertFalse(file.isFolder());
         assertTrue(manager.canCreateFileSystem(file));

         final VFSClassLoader loader = new VFSClassLoader(file, manager);
         final URL resource = loader.getResource("read-tests/file1.txt");
         assertNotNull(resource);
     }

the first check is verifying the bug is fixed, by adding a directory to  
the search path and requesting a resource from it. The second check is  
testing the still expected function to add a jar file to the classpath (I  
noticed this important function seems not to be execised by any test?).

the code to setup the manager is ugly and I tried varios variations, this  
is just the latest incarnation.

One option would be to run those tests in a testcase which is not repeatet  
for all providers, but I think it would be cool if we can actually keep it  
there.

Greetings
Bernd

PS: my pull request did not create a dev@commoins mail, I filed a Jira for  
that as well:
https://issues.apache.org/jira/browse/INFRA-6764

Am 16.08.2013, 23:31 Uhr, schrieb Bernd Eckenfels <[hidden email]>:

> Hello,
>
> I want to use the VFSClassLoader on JAR files and Directories (to  
> provide resources). My problem is, that some directories are exploded  
> archives and have a name with a .jar extension.
>
> The addFileObjects() of the VFSClassLoader uses canCreateFileSystem() to  
> detect, if for a given file is a overlay which can read its content.  
> However this method uses FileTypeMap#getScheme(file) which does look at  
> the mimetype and extension of the file name, but not if it is actually a  
> file.
>
> I think VFSClassLoader can check for hasContent() but I think that the  
> solution should actually somewhere in canCreateFileSystem() as I could  
> image there is a overlay filesystem which maps a directory into a  
> filesystem (think .git).
>
> Any ideas? Should I provide a patch for VFSClassLoader only to start  
> with?
>
> Gruss
> Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]