You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <gg...@seagullsw.com> on 2003/11/13 20:19:44 UTC

[vsf] WAS: [general] Zip file proxy?

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

Re: [vsf] WAS: [general] Zip file proxy?

Posted by "Todd V. Jonker" <To...@ConsciousCode.com>.
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"
<gg...@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