[
https://issues.apache.org/jira/browse/VFS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16916685#comment-16916685
]
Michiel Hendriks commented on VFS-444:
--------------------------------------
I am working on a patch for this issue as I ran into the problem of using an
URI like {{jar:res:foo/bar.jar}}
I have got that part working. But now I'm incorporating Xavier's test cases.
The way resource loading works from the Java ClassLoader is that locations are
always absolute, there is no such thing as relative locations. So,
"res:META-INF/config.xml" is an absolute location.
The patch I'm creating will have ResourceFileNames with the specified uri like
"res:META-INF/config.xml".
The above test cases also have URIs like:
* res:/META-INF/config.xml
* res://META-INF/config.xml
Both should be invalid uri's.
The former because ClassLoader.getResource('/META-INF/config.xml') returns null.
The latter because the '//' after the schema is used to identify that following
it should be an "authority". But there is no such thing as authority. (1)
So I am inclined to have the above cases to always fail for '/' and '//'
prefixes. Currently they have mixed results, so that's no good.
(1) in the file protocol they support the empty authority, hence the three
slashes: {{file:///}} but I don't think it's a good idea to support that too.
> ResourceFileProvider "res://" failed to obtain FileObject from resolved
> FileName
> --------------------------------------------------------------------------------
>
> Key: VFS-444
> URL: https://issues.apache.org/jira/browse/VFS-444
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0
> Environment: java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
> Linux x 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
> Reporter: Walter Eaves
> Priority: Major
> Labels: common-configuration
> Fix For: 2.0
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Given
> // See if we can find it in the resources.
> String s0 = "res://config.xml";
> FileName n0 = mgr.resolveURI(s0);
> FileObject c1 = mgr.resolveFile(new File(n0.getBaseName()), n0.getPath());
> logger.info("c1: " + c1 + " : " + c1.exists());
> The code seems to have worked because, I can see the logger has the right URL
> in the SoftResFilesCache
> 12:43:29,734 DEBUG [StandardFileSystemManager] Skipping provider
> "org.apache.commons.vfs2.provider.webdav.WebdavFileProvider" because required
> class "org.apache.jackrabbit.webdav.client.methods.DavMethod" is not
> available.
> 12:43:29,765 DEBUG [SoftRefFilesCache] putFile:
> file:///misc/build2/fpstats0/fpstats-experimental/config.xml
> 12:43:29,767 DEBUG [SoftRefFilesCache] putFile: file:///config.xml
> 12:43:29,767 INFO [Version] c1: file:///config.xml : false
> The file is there!
> But I cannot get a FileObject that gives me the absolute path.
> This would be useful for me. I want to be able to resolve a file out of the
> resources: jar files and classes/ directories. And keep that in reserve as I
> try and resolve the same file in -Duser.home and elsewhere.
> If it worked, and I believed it, I could then use the "res://config.xml" it
> for commons-configuration.
> But I can't.
> I just don't understand the API - is it complete? I can resolve a URL and get
> a FileName, but it won't tell me the FileSystem(s) without that I can't
> resolve it in this SoftResFilesCache.
> If it were me, I would just open the SoftResFilesCache and add a search for
> the base filename of a URL across all FileSystems.
> I use a filesystems to find things. I give it a hint where I saw it last and
> I want to track if it is still there and whether it has changed.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
