You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Brian Oxley <bo...@simdesk.com> on 2005/01/10 23:33:42 UTC
LocalFile package-protected and final: why?
Why is org.apache.commons.vfs.provider.local.LocalFile package-protected
and final? I'd like to extend it in a provider with a very
LocalFile-like FileObject and FileName.
Cheers,
--binkley
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] LocalFile package-protected and final: why?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Matthijs Wensveen wrote:
> How impossible would it be to have java.io.File subclasses as wrappers
> around vfs?
The java.io.File itself might not be the problem. One could override and
replace all its methods.
But java's FileInputStream et al wont be happy with them as they use
FileDescriptors and e.g. FileInputStream.open() is a native method. :-(
If a 3rd Party library tries to pass the wrapped VFS-File to them they fail.
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] LocalFile package-protected and final: why?
Posted by Matthijs Wensveen <mr...@wanadoo.nl>.
Brian Oxley wrote:
> [A quick meta-question: is this list the right place for technical
> questions of this sort? I don't want to spam the uninterested.]
>
> Mario Ivankovits wrote:
>
>> Before I decide to make it public (and non final) could you please
>> explain in short what you try to do?
>
>
> I'm working to persuade my group to drop an inhouse implementation of
> a java.io.File-extended hierarchy and switch to VFS's
> FileName/FileObject instead. We have a mess; you have a clean design.
>
I've been thinking about extending java.io.File to implement vfs-alike
functionality. Are there any good reasons not to do this (other then
that commons-vfs is already available)? Having a subclass of
java.io.File would allow you to use your objects with 3rd party
components and other java classes that work with files too.
How impossible would it be to have java.io.File subclasses as wrappers
around vfs?
Just some random thoughts. Regards,
Matthijs
PS. I hope this answers your meta-question :)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [VFS] broken link in site
Posted by Mario Ivankovits <ma...@ops.co.at>.
Edgar Poce wrote:
> Hi
> there's a broken link at
> http://jakarta.apache.org/commons/sandbox/vfs/api.html under the
> examples subsection.
Fixed - Thanks!
Will be reflected on the website during the next regeneration - for now
you could use
http://jakarta.apache.org/commons/sandbox/vfs/apidocs/org/apache/commons/vfs/example/package-summary.html
Uhm ... but dont expect too many examples :-(
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[VFS] broken link in site
Posted by Edgar Poce <ed...@gmail.com>.
Hi
there's a broken link at
http://jakarta.apache.org/commons/sandbox/vfs/api.html under the
examples subsection.
regards
Edgar
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] autoupdate SNAPSHOT for maven
Posted by Mario Ivankovits <ma...@ops.co.at>.
Brian Oxley wrote:
> Would you mind updating the SNAPSHOT build for Maven?
>
> I usually pull from there for projects so that a maven build can show
> the dependency on commons-vfs.
>
> Is there some way for you to automate this process? I feel awkward
> asking each time something interesting happens with the project.
Hmmm. Dont know, but I think this is not possible.
However - if you do not require the name SNAPSHOT but say NIGHTLY I
could setup a cron-job which could do this.
My feeling about a SNAPSHOT is something different. I think a SNAPSHOT
should be stable at least for a couple of days.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] LocalFile package-protected and final: why?
Posted by Brian Oxley <bo...@simdesk.com>.
Mario Ivankovits wrote:
> There was already a messy in the used signatures, so I decided to change
> the all filesystem-classes accordingly to allow better reusability.
> The next nightly or a cvs checkout should allow you to override the
> needet classes.
Great!
Would you mind updating the SNAPSHOT build for Maven?
I usually pull from there for projects so that a maven build can show
the dependency on commons-vfs.
Is there some way for you to automate this process? I feel awkward
asking each time something interesting happens with the project.
Thanks,
--binkley
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] LocalFile package-protected and final: why?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Brian Oxley wrote:
> [A quick meta-question: is this list the right place for technical
> questions of this sort? I don't want to spam the uninterested.]
commons-dev - where else if not here ;-)) You are welcome.
> (why is it not LocalFileObject, BTW? I'm a nit for consistency.)
You are right, but I dont know why.
> I was hoping to simply extend LocalFile and override the few spots
> that differed (such as supporting attributes).
There was already a messy in the used signatures, so I decided to change
the all filesystem-classes accordingly to allow better reusability.
The next nightly or a cvs checkout should allow you to override the
needet classes.
Hope this helps.
Ciao,
Mario
Re: [vfs] LocalFile package-protected and final: why?
Posted by Brian Oxley <bo...@simdesk.com>.
[A quick meta-question: is this list the right place for technical
questions of this sort? I don't want to spam the uninterested.]
Mario Ivankovits wrote:
> Before I decide to make it public (and non final) could you please
> explain in short what you try to do?
I'm working to persuade my group to drop an inhouse implementation of a
java.io.File-extended hierarchy and switch to VFS's FileName/FileObject
instead. We have a mess; you have a clean design.
Of the existing providers, local is the best fit to our file-like
objects so I wanted to extend LocalFile (why is it not LocalFileObject,
BTW? I'm a nit for consistency.) I was hoping to simply extend
LocalFile and override the few spots that differed (such as supporting
attributes).
Simply as a matter of preference, I dislike final classes as it
discourages reuse. I know this is not a clear-cut issue.
Cheers,
--binkley
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vfs] LocalFile package-protected and final: why?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Brian Oxley wrote:
> Why is org.apache.commons.vfs.provider.local.LocalFile
> package-protected and final? I'd like to extend it in a provider with
> a very LocalFile-like FileObject and FileName.
Dont know the reason of the original authors, but I think they wanted to
create a safe and clean object structure.
Before I decide to make it public (and non final) could you please
explain in short what you try to do?
Thanks!
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org