commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Poulard <>
Subject Re: [VFS] Why resolveFile API doesn't accepting URI ?
Date Mon, 17 Jul 2006 11:11:44 GMT
Vincent Massol wrote:
> Hi Philippe,
>>-----Original Message-----
>>From: Philippe Poulard []
>>Sent: lundi 17 juillet 2006 11:28
>>To: Jakarta Commons Users List
>>Subject: Re: [VFS] Why resolveFile API doesn't accepting URI ?
>>Vincent Massol wrote:
>>>Hi Mario,
>>>>-----Original Message-----
>>>>From: Mario Ivankovits []
>>>>Sent: lundi 17 juillet 2006 08:25
>>>>To: Jakarta Commons Users List
>>>>Subject: Re: [VFS] Why resolveFile API doesn't accepting URI ?
>>>>>I've just tried to use VFS and I was surprised to see that the
>>>>>API does not have a signature accepting a URI object.
>>>>I think (this decision were felt before I jumped to VFS) the main reason
>>>>is, that vfs supports "layered" URIs. So you can have
>>>>The java URI class cant really deal with this, can it?
>>>I think it can. See
>>>They give this example in the javadoc:
>>>In addition the general format is: [scheme:]scheme-specific-
>>>I'm not an expert but I guess one could consider that the scheme is
>>>"tar:gz:http" in your example above.
>>not at all : the scheme is "tar" and the scheme specific part is the
>>remainder ; 
> Ah right. As I said I'm not an expert ;-)
>>unfortunately, the URI class doesn't perform further parsing
>>for the other parts because the RFCs doesn't specify a separator ; VFS
>>uses "!"
> What do you think would not work if VFS used an URI class? It seems to me
> that getScheme() and getSchemeSpecificPart() will always return the full
> URI, no?
> I wrote a little unit test to ensure I understand what's going on:
> public void testURI() throws Exception
> {
>     URI uri1 = new URI("file://c:/anyhost/dir/mytar.tar.gz");
>     assertEquals("file", uri1.getScheme());
>     assertEquals("//c:/anyhost/dir/mytar.tar.gz", 
>         uri1.getSchemeSpecificPart());
>     assertEquals("c:", uri1.getAuthority());
>     assertEquals("/anyhost/dir/mytar.tar.gz", uri1.getPath());
>     URI uri2 = new URI("tar:gz:http://anyhost/dir/mytar.tar.gz!/mytar.tar!"
>         + "/path/in/tar/README.txt");
>     assertEquals("tar", uri2.getScheme());
>     assertEquals("gz:http://anyhost/dir/mytar.tar.gz!/mytar.tar!"
>         + "/path/in/tar/README.txt", uri2.getSchemeSpecificPart());
>     assertNull(uri2.getAuthority());
>     assertNull(uri2.getPath());
> }
> As the general format is "[scheme:]scheme-specific-part[#fragment]" if we
> used only the getScheme() and getSchemeSpecificPart() APIs wouldn't it work
> just fine?

URIs are classified in opaque URIs and hierarchical URIs ; the uri1 in 
your example is hierarchical, the uri2 is opaque, but it looks like a 
hierarchical URI ; what we can't do with opaque URIs ? well... resolving 
a relative URI regarding it

> The scheme-specific part would be parsed as it's currently done.
> In other words what do you think wouldn't work if we used the URI Java
> class?

if you have to resolve URIs upon a base URI, you'll certainly have some 
troubles if you have "layered" URIs à la VFS

what you need is a specific class that understand "layered" URIs ; it 
could be a class based on the existing URI class ; what you have to do 
is to test if you have an opaque URI if the scheme specific part up to 
the last "!" is itself an URI

VFS works like this


              (. .)
|      Philippe Poulard       |
        Have the RefleX !

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message