Re: [VFS] Softening the exceptions...

Hi! Am 25.10.2010 um 21:13 schrieb James Carman ja...@carmanconsulting.com: On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory ggreg...@seagullsoftware.com 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.

Re: Exclusive broker access

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

RE: [vfs] JDK 1.5

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. Probably

AW: [VFS] Minimum Java version

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

RE: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java

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 options

RE: svn commit: r797267 - in /commons/proper/configuration/trunk/src/java/org/apache/commons/configuration: FileSystem.java VFSFileSystem.java

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, +

AW: [vfs] MemcachedFilesCache for Google App Engine (object serialization)

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,

AW: [vfs] Google App Engine plug-in (GaeVFS)

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 an

RE: [vfs] LRUFilesCache safe for production use? Google App Engine/Java plug-in

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 other

[vfs] caching (was: [vfs] LRUFilesCache safe for production use? Google App Engine/Java plug-in)

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-trivial.

RE: [vfs] LRUFilesCache safe for production use? Google App Engine/Java plug-in

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 ma...@ops.co.at wrote: Hi! 1. Is the LRUFilesCache safe for production use? GAE/J won't allow using the default

RE: [vfs] Dependency to compress

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

RE: [VFS] anonymous debug logging

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 just

RE: [VFS]HttpConnectionManager

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? Sorry, I

RE: [VFS]HttpConnectionManager

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

RE: [VFS] tests and project status

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 instead of

RE: [VFS] tests and project status

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 ralph.go...@dslextreme.com wrote: Is anyone actively

RE: [configuration] Interface vs class

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 compatibility.

Re: [lang] Java 5

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 *

[vote][vfs] set minimum java version to 1.5

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

Re: [vote][vfs] set minimum java version to 1.5

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

[vfs] vfs2 or plain wrapper mode

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

Re: [vfs] vfs2 or plain wrapper mode

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

Re: [vfs] vfs2 or plain wrapper mode

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 ;-) Ciao,

Re: [configuration] JSON format

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, Mario

Re: [vfs] VFS 1.0 CIFS

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

Re: [vfs] VFS 1.0 CIFS

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:

Re: [all] GSoC

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

Re: commons-vfs current status?

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

Re: [vfs] Re: Specifying options to FTP etc..

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=ABCTYPE=PDFvfs.proxyHost=proxy.hostvfs.proxyPort=8080 Yes, for sure,

Re: [vfs] Re: Specifying options to FTP etc..

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