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 <e...@zusammenkunft.net>:
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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
