Hi, If we go down this path, Paul please make sure the main log4j build doesn't depend on VFS, only Chainsaw. I have full faith in Mario and his VFS-related ideas (I like them and look forward to seeing them), but with lo4j 1.3 alpha really close I don't want to add another dependency to the log4j core, especially an immature/less tested component like VFS.
I'm cc'ing log4j-dev but let's continue this discussion in one place, e.g. here ;) Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: Mario Ivankovits [mailto:[EMAIL PROTECTED] >Sent: Friday, May 14, 2004 7:28 AM >To: Jakarta Commons Developers List >Subject: Re: [VFS]: Integration - too early? > >Paul Smith wrote: > >>The certificate that I would signing with would display my >[EMAIL PROTECTED] >>email inside it. Now obviously I wouldn't have written a single line of >the >>commons code, and just wanted to make sure no-one can foresee a problem >with >>that. We'd obviously give appropriate credit within Chainsaw to the >>commons-dev team. >> >> >As far as i understand the community idea - there should be no problem >with this. At least not for me. > >>* Is VFS still in a state of flux? >> >> >Well - quite some time not much happened in VFS - i picked it up now and >try to implement what ever comes in my head. >However - i try not to change the current api too much. Maybe to one or >other method will be added. >I will be happy to work together with the log4j team to make the >integration into chainsaw reality. > >>* Does VFS have a feature to dynamically detect which file systems are >>'available'? >> >> >Yes - one of the methods to get a filesystemmanager is by using the >StandardFilesytemManager - it uses a providers.xml where the possible >filesystem-types are defined and also the needet classes. >If the dependency check failes the provider is not available. > >e.g. > <provider >class-name="org.apache.commons.vfs.provider.http.HttpFileProvider"> > <scheme name="http"/> > <if-available >class-name="org.apache.commons.httpclient.HttpClient"/> > </provider> > >>* This might be File system specific, but does anyone know whether, for a >>given FileObject, one might be able to read a portion of the, say, text >>file, and only grab the first X lines of it for a preview? >> >Currently a simple InputStream is provided. As always you could wrap it >e.g. into an BufferedReader and use readLine(). >So the answer is YES. >However - we have to check how e.g ftp react if you close the stream in >the mid of the transfer. > >One of the things i would implement in the future is to provide access >to the file by some sort of RandomAccessFile - for sure - for the >filesystems where it is possible. >But it should be possible to use the restart-capability of some >ftp-server to simulate this behaviour. > >>* I don't know much about SFTP, but does this support the ability to >>'browse' a remote directory? >> >YES. >This brings me back to the previous question. >Currently the SFTP provider reads the complete file into memory - i have >to check if this is still needet. >But even if i change this - it is transparent to the above outlined >solution. > >>I assume if one has setup certificate-based authentication for a local ssh >with a remote >>location, the password wouldn't even be needed here. Would that work? (ie >>the usual ~/.ssh/authorized_keys file etc) >> >> >This should work too - but i will test this again. >Another problem here is the fact, that it is not easily possible to find >the location of the key-files on the client side - the current code >tries to figure out some places: >1) check "vfs.ftp.sshdir" system-property >2) check "user.home"/.ssh >3) check c:\\cygwin\\home\\"user.name"\\.ssh > >I DEFINITELY WILL CHANGE THIS. >I know from some old communication between the original authors and me, >that they never ever wanted to use system-properties - all has to be >configured by the application. >In the past it was a problem to send some configuration to the >filessystem - now it is not. > >>That's all I can think of for now. If anyone is interested in trying out >>the current stable version of Chainsaw >> >I currently use the cvs-head version of chainsaw2 (and a patched >commons-logging). The chainsaw stuff was motivation enough to change our >complete custom loggin solution to commons-logging with log4j as backend. >Keep on going !!! > >-- Mario > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
