Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <3FB51DCB.3080807@anthonyeden.com>
Date: Fri, 14 Nov 2003 13:24:11 -0500
From: Anthony Eden <me@anthonyeden.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [vsf] WAS: [general] Zip file proxy?
References: <245A7290F0E0D311BF6E009027E7908B07204982@atlanta.seagullsw.com>
In-Reply-To: <245A7290F0E0D311BF6E009027E7908B07204982@atlanta.seagullsw.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Just to add my two cents I am against subclassing java.io.File in VFS.  
In most cases the easest way to add support for VFS in systems which 
aren't already VFS-enabled is to provide additional constructors and 
methods which will just convert the java.io.File object to VFS FileObject.

-Anthony

Gary Gregory wrote:

>I agree with the points made /but/, the reason I would like a File subclass
>is to allow me to get the "use a zip file as a directory" feature for free,
>as in, not-change-any-of-my-giant-pile-of-code free.
>
>Gary
>
>  
>
>>-----Original Message-----
>>From: Todd V. Jonker [mailto:Todd@ConsciousCode.com]
>>Sent: Thursday, November 13, 2003 13:39
>>To: Jakarta Commons Developers List
>>Subject: Re: [vsf] WAS: [general] Zip file proxy?
>>
>>Subclassing io.File makes me rather uneasy.  Most of its methods just
>>doesn't make sense for "virtual files" like those inside an archive.
>>Even basic stuff like getPath() and getParent() become very problematic.
>>What you need is something *more general* than a file, that just provides
>>stuff like getURL() and getReader().  I haven't looked at VFS in a while,
>>but I seem to recall that it provided something along those lines.
>>
>>BTW is VFS alive?  I've been hesitant to use it (and I *really* want to
>>use it) because its apparently been languishing in the sandbox, and I
>>don't want to code to unreleased projects.  If the original developers
>>have moved on, I'd be interested in helping to resurrect it.
>>
>>.T.
>>
>>
>>On Thu, 13 Nov 2003 14:19:44 -0500, "Gary Gregory"
>><ggregory@seagullsw.com> said:
>>    
>>
>>>Ah, yes, I do recall seing this component, it quite impressive. Could a
>>>[vsf] developer comment on the possibility of a java.io.File subclass
>>>      
>>>
>>(or
>>    
>>
>>>subclasses)? I'd rather not port code...
>>>
>>>Gary
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: Inger, Matthew [mailto:inger@Synygy.com]
>>>>Sent: Thursday, November 13, 2003 10:53
>>>>To: 'Jakarta Commons Developers List'
>>>>Subject: RE: [general] Zip file proxy?
>>>>
>>>>Try commons-vfs
>>>>
>>>>under the sandbox.  You can't treat it as a java.io.File, but there
>>>>is a seperate FileObject which abstractly represents a file from any
>>>>given file system.  Some of the supported filesystems include local,
>>>>jar,zip,http,ftp,cifs (windows share),etc...
>>>>
>>>>Comes with a nice set of ANT tasks as well. :)
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Gary Gregory [mailto:ggregory@seagullsw.com]
>>>>Sent: Thursday, November 13, 2003 1:49 PM
>>>>To: 'Jakarta Commons Developers List'
>>>>Subject: [general] Zip file proxy?
>>>>
>>>>
>>>>Hello,
>>>>
>>>>Does anyone know of a doo-dad in Commons or somewhere that would allow
>>>>        
>>>>
>>me
>>    
>>
>>>>to
>>>>use a .zip file (and other compressed format) as java.io.File
>>>>        
>>>>
>>/directory/.
>>    
>>
>>>>What I have found so far (can't recall now) only works if your code
>>>>        
>>>>
>>uses a
>>    
>>
>>>>whole framework of proxies/wrappers. Ideally, such a subclass of File
>>>>should
>>>>let me traverse the archive just as if it were a directory on disk,
>>>>        
>>>>
>>which
>>    
>>
>>>>would allow my current pile of File-based code to work as is.
>>>>
>>>>Thanks,
>>>>Gary
>>>>        
>>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>    
>>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org