Return-Path: Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org Received: (qmail 41295 invoked from network); 17 Jul 2006 11:13:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Jul 2006 11:13:44 -0000 Received: (qmail 24459 invoked by uid 500); 17 Jul 2006 11:13:39 -0000 Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org Received: (qmail 24388 invoked by uid 500); 17 Jul 2006 11:13:38 -0000 Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Users List" Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 24377 invoked by uid 99); 17 Jul 2006 11:13:38 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Jul 2006 04:13:38 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [138.96.64.20] (HELO sophia.inria.fr) (138.96.64.20) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Jul 2006 04:13:36 -0700 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.7/8.13.4) with ESMTP id k6HBDDkc003389 for ; Mon, 17 Jul 2006 13:13:13 +0200 Received: from [138.96.66.4] (dahu.inria.fr [138.96.66.4]) by sophia.inria.fr (8.13.7/8.13.4) with ESMTP id k6HBBied002962 for ; Mon, 17 Jul 2006 13:11:44 +0200 Message-ID: <44BB7070.2070807@sophia.inria.fr> Date: Mon, 17 Jul 2006 13:11:44 +0200 From: Philippe Poulard User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050511 X-Accept-Language: fr-FR,en MIME-Version: 1.0 To: Jakarta Commons Users List Subject: Re: [VFS] Why resolveFile API doesn't accepting URI ? References: <00d201c6a98c$e5c24eb0$6601a8c0@massol> In-Reply-To: <00d201c6a98c$e5c24eb0$6601a8c0@massol> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Mon, 17 Jul 2006 13:11:44 +0200 (MEST) X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Vincent Massol wrote: > Hi Philippe, > > >>-----Original Message----- >>From: Philippe Poulard [mailto:Philippe.Poulard@sophia.inria.fr] >>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 [mailto:mario@ops.co.at] >>>>Sent: lundi 17 juillet 2006 08:25 >>>>To: Jakarta Commons Users List >>>>Subject: Re: [VFS] Why resolveFile API doesn't accepting URI ? >>>> >>>>Hi! >>>> >>>> >>>>>I've just tried to use VFS and I was surprised to see that the >>>> >>>>resolveFile >>>> >>>> >>>>>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 >>>>tar:gz:http://www....... >>>>The java URI class cant really deal with this, can it? >>> >>> >>>I think it can. See >>>http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html >>> >>>They give this example in the javadoc: >>>urn:isbn:096139210x >>> >>>In addition the general format is: [scheme:]scheme-specific- >> >>part[#fragment] >> >>>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 -- Cordialement, /// (. .) --------ooO--(_)--Ooo-------- | Philippe Poulard | ----------------------------- http://reflex.gforge.inria.fr/ Have the RefleX ! --------------------------------------------------------------------- To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-user-help@jakarta.apache.org