Hi!
Am 25.10.2010 um 21:13 schrieb "James Carman" :
> On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory
> wrote:
>>
>> So for VFS, you would prefer that all error handling be done with unchecked
>>
>
> In a nutshell, yes. So, it's a pretty easy change. You'd just change
> the superclass of Fil
We are sorry we have to inform you that this functionality is not yet
implemented, but is planned for the Q1 release in 2019.
;-)) sorry, couldn't resist ... I guess, you wouldn't want your mail sent to
commons-dev, no?
Ciao,
Mario
-Ursprüngliche Nachricht-
Von: Emmanuel Bourg [mailt
Hi!
> looking at Ralph's comment in
> https://issues.apache.org/jira/browse/VFS-254
> I am questionning myself, if there's any reason why vfs 2.0 should
> still
> have JDK 1.4 as requirement and not JDK 1.5.
If it is just me, I'd be happy to drop 1.4 dependency - Past votes were
declined. Prob
> Well, if you're going to make a jump, why go to something that's EOSL very
> soon?
For me, JDK 1.6 would be fine too.
But, I'd say this is just a minor issue as the main things one will notice
(generics, enhanced for syntax) are there with JDK 1.5.
Are there any API changes critical for VFS to
Hi!
+1 on Java 5.
> Are they going to change the package name?
Let's discuss this once we cross this bridge.
Ciao,
Mario
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@co
Hi!
> System.err.println(".");
> System.gc();
> Thread.sleep(1000);
>
> SoftReferences are triggered by low memory, but not by number of gc
> calls.
> AFAICS this simply slows down the tests tremendously, but have no real
> effect.
Hmmm during my tests, I have seen ja
Hi!
> > IF you use the options in a way which allows you to know which kind
> > of filesystem will be used - good - but then the builder is just
> > another layer, but not awkward and brittle I think.
>
> No. They are awkward and brittle. WebDavFileSystemConfigBuilder
> extends HttpFileSystemCon
Hi!
> From personal experience, I've found working with it
> to be awkward and brittle. I would much prefer to have each provider
> subclass FileSystemOptions and provide the getters and setters there. Then,
> at least, you could do an instanceof on the FileSystemOptions and determine
> what optio
Hi!
Using weak ref as default seems not too bad. However, since the file objects
have just their parent cached it might lead to much more file system access
then now as a parent might need to refresh its children.
I tried to kick a discussion about caching at all already [1].
I still think goi
Hi!
> Modified:
> commons/proper/configuration/trunk/src/java/org/apache/commons/configur
> ation/VFSFileSystem.java
> -private FileSystemOptions setHttpOptions(FileSystemOptions opts,
> Map map)
> +private void setProperty(FileSystemConfigBuilder builder,
> FileSystemOptions options,
Hi!
> I think the answer is: the FilesCache is used to optimize resolveFile()
> performance, and to reuse FileObject instances, but is not used to cache the
> actual file content.
Thats correct!
Ciao,
Mario
-
To unsubscribe, e
Hi!
>> http://gaevfs.appspot.com/
cool stuff!
> This is kind of cool. My first thought was that it might be nice to
> include it in VFS itself, but after looking at
> http://code.google.com/appengine/terms.html
> I have my doubts that including this at Apache would be doable even
> as a
> before ages VFS included the compress classes with own namespace,
> cause compress wasn't released and VFS had to go ahead. It was planned
> to replace those vfs.compress classes with a dependency to commons
> compress. If this is still the plan, I will create an issue for it and
> would do it st
can close() the filesystem
when the servlet is destroyed. In this case, I should be OK using
LRUFilesCache?
Thanks,
Vince
On Tue, May 26, 2009 at 2:28 AM, Mario Ivankovits wrote:
> Hi!
>
> > 1. Is the LRUFilesCache safe for production use? GAE/J won't allow usin
Hi!
> Actually, I commented out the call to filesystemclose in
> SoftRelFilesCache. While looking at the FileSystem implementation I
> realized that the way close is implemented is not thread safe and
> can't be called while the system is running. I believe the fix for
> this is non-triv
Hi!
> 1. Is the LRUFilesCache safe for production use? GAE/J won't allow using
> the default SoftRefFilesCache because it doesn't allow background threads.
> I 've found a few really old messages saying things like "SoftRefFilesCache
> is the only implementation suitable for production use" and "o
> >> Nice would be, as opposite to the , to have a global
> >> , no?
> >>
> >> That way, problems like this are sorted out once and for all.
> >>
> >
> > +1
> Jochen, you do realize that global exclusions would suffer from the same
> problems as you described in the A B C scenario.
The same p
Hmmm
Couldn't we ask the maven devs to extend the pom to allow "global excludes"?
The only thing this 0.0 stuff solves, is, that the user does not need to
exclude commons-logging from each and every dependency.
What you can do ... and what I did.
Nice would be, as opposite to the , to have
Hi!
> > Have an idea to change FileName implementation to use Java's
> > internal URI,
> > and it need to be discussed first. 2.0 release may be the only good
> > point to
> > do that in next few years :)
> >
>
> There are a bunch of places where URI should have been used.
Please keep in mind th
Hi!
> From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
>
> I'm not a big fan of that.
Me too, any decent logging facility should allow to configure the logger on a
"per package" level, so no problem to make the logging silent for a given
package.
> I'd prefer to switch to SLF4J and jus
Hi!
> -Original Message-
> From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> Sent: Monday, February 23, 2009 8:29 AM
>
> Thanks Mario. VFS-164 wasn't really clear. Was the problem the limit
> to 2 connections per host that MultiThreadedHttpConnectionManager has
> by default?
Sorr
Hi!
> -Original Message-
> From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
> Sent: Monday, February 23, 2009 7:28 AM
>
> What I'd like to know is, was there more to VFS-164 than is stated in
> the issue and is this change sufficient? Or do I need to create yet
> another HttpConnectio
> > Great to see that there is some development with VFS again! It's
> > more motivating to work in a team :-)
> >
>
> Thanks. I just set myself back a little bit though. It must be
> getting late. I have been trying to get the checkstyle reports to work
> and I somehow managed to remove trunk in
Hi!
> From: tcu...@vafer.org [mailto:tcu...@vafer.org] On Behalf Of Torsten
> Curdt
> Sent: Monday, January 05, 2009 1:41 AM
> To: Commons Developers List
> Subject: Re: [VFS] tests and project status
>
> On Mon, Jan 5, 2009 at 00:43, Ralph Goers
> wrote:
> > Is anyone actively working on common
Hi!
> > Look through the archives, the discussion with pros and cons went on
> > promoting commons-proxy.
>
> Yes they did! I remember it well and I hated using a class rather
> than an interface. However, I can see the merit in the decision when
> it comes to maintenance and backward compatibi
Hi!
What do you guys see being the big difference between the 2 approaches
and is that a good enough reason to keep both libraries?
VFS contains an old snapshot of compress just to being able to cut a
release.
Actually, compress is slowly evolving, once this has been finished we
will remo
Hi!
+1 on generics
+99 on package-name change.
+100
The ASM project (org.objectweb.asm) changes their API significantly with
major releases, but do not change the package name. And it causes major
pain. For example, the following libs all require specific versions of ASM:
* hibernate
* dr
Hi!
It's easy enough to get 1.3 from java.sun.com ... I also got 1.2 and
1.1 from there recently.
Ah, yes, now I found it too, it's in archive.
Since the API might not drastically change it should not be required to
rename the package to vfs5 or vfs2 or whatever.
Not sure I understa
Hi!
Since it is not that easy to get in touch with a jdk 1.3 (or I tried not
hard enough ;-) ) I'd like to ask if everyone is fine to start VFS 2
with jdk1.5?
As long as no other development need requires it to enhance the VFS 2
api I do not plan to introduce generics yet (I don't see that m
Hi!
> Sounds like your
> solution would work for directories as well, if VFS didn't attempt to
> enumerate all the files in all the directories along the path?
>
Yes, that is the plan :-)
What I wrote about files count for directories too, for me this
attribute is just a different value ;-)
Cia
Hi Martin!
> Just wondering, how would a client of VFS enumerate
> Just the folders in a directory e.g. in order to
> Render a tree of files?
>
As today. Disabling the file-type determination should be optional only
and isn't something I'd change during the first development iteration.
The diff
Hi!
Probably I find some time during the next weekend to fix a long standig
bug in VFS regarding dealing with hidden or special files.
The main problem I see is that VFS tries to act more like a real
filesystem than a simple wrapper.
VFS tries to determine the filetype (FILE, DIR, VIRTUAL) and th
Hi!
>> JSON is a subset of Javascript,
>> so we can use a simple call "eval()" to parse the configuration file.
Wouldn't that be dangerous for something like "script injection"?
One might be able to pass in a faked JSON string with some code in there
which will be executed on eval() then, no?
Ciao
Hi!
> Is there a problem with placing the jar in
>
> http://people.apache.org/repo/m2-snapshot-repository/
>
Hmmm shouldn't this be something the nightly build should do already?
Ciao,
Mario
-
To unsubscribe, e-mail: [E
Hi!
>> What's the recommended way of using commons-vfs 1.0 with CIFS support?
>
> You mean where to get the SMB provider from?
>
> Supposed to be in the vfs sandbox ...Mario?
Sorry for being late, wasn't able to connect to our mailserver through
the JSFDays conference network.
Yepp, still in the s
Hi!
> Any idea for GSoC [1]? I think it would be worth participating
VFS or IO: File Alteration Monitor with native support (I can sponsor
some basic code-base for linux). If it is located in IO or in another
package it should be possible to plugin VFS. Means, should not deal with
plain java.io.Fil
Hi,
>IMHO major problem is the necessary environment. You may have one or two of
>the supported external virtual file systems, but as soon as you start to
>modify core classes, you have no clue about the effects for the other systems
>... :-/
There exists a VMWare image with everything setup
Hi!
> I've been using the project for the last 6 months or so and haven't seen
> very many commits or activity on JIRA. Is there intention for on going
> support?
>
As long as no code work needs to be done I think support is still there.
Unhappily VFS lacks of developers and my time is limited
Hi!
>> - go for 1.5
>> - take advantage of generics
> +1!!! Frankly speaking this is probably applies to most of commons.
>
> If commons wants to stay relevant and not become just legacy we also
> need to take some steps forward.
+1 ... long overdue maybe too long!?
Ciao,
Mario
Hi!
> https://issues.apache.org/jira/browse/VFS-178 - allows options (such
> as ?vfs.passive=true to be used with FTP URLs)
I've added a comment to this issue.
> http://issues.apache.org/jira/browse/VFS-106 - adds a Zip provider
> using TrueZip (TrueZip is available on Maven central now)
Normally,
Hi!
Maybe it would make more sense to do these changes in commons-jci-fam
first and then move that to a new commons-fam?
Sounds reasonable, although I still think IO is a better home for fam
than a separate component.
In any case, it would be creat if the code is built in a way that makes
Hi!
> I think the use of the ?? would not be a good URI scheme. However, maybe we
> could simply make the VFS parameters unique. For example add vfs. in front
> of them.
>
> For example,
> http://www/path/cgi-bin/send.pl?FILE=ABC&TYPE=PDF&vfs.proxyHost=proxy.host&vfs.proxyPort=8080
>
Yes, for
Hi!
> I think we should leave it upto the scheme to decide. So http may
> decide to pass it to the server, while ftp may decide to use it to
> talk to the server. i.e. each implementation will know the options
> they understand, enforce them and pass any remainder to the server.
> How does that s
Hi!
> I don't quite agree with this - this may be the common case for HTTP,
> but the URI spec does not enforce it.
Ok, but how should we differentiate between these both use-cases?
If we would like to allow this style of URL we need some special
delimiter to know what to pass to VFS as configura
Hi!
> I am trying to use VFS to connect to a FTP file, but the problem is
> that I cannot specify that PASSIVE mode should be used.
It is possible through the *FileSystemConfigurationBuilder stuff only.
> ftp://myusername:[EMAIL PROTECTED]/pub/downloads/somefile.tgz?option=value
>
>
> Have I misse
Hi!
It is an interesting topic (to underline this: I am sitting here on vacation
for a hadful of days using my mobile to write this mail ;-) ), though, due to
some other OS projects I am really getting out of time.
Anyway, the j.i.file way of truezip is the case why I didnt support this idea
ac
46 matches
Mail list logo
