logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Smith <Paul.Sm...@lawlex.com.au>
Subject RE: [VFS]: Integration - too early?
Date Fri, 14 May 2004 23:10:19 GMT
Guys, I just reviewed my original email about this, and I SWEAR I put
log4j-dev on the CC list, but it looks like it did not get through, my
apologise.  Hopefully you can read the full email from Yoav's email properly
putting this list back in (thanks Yoav for spotting it).  Certainly not my
intention to leave this list off the discussion.

For VFS specific discussions I will probably be communicating directly with
commons-dev, but anything that affects Chainsaw I will definately keep this
list in the loop.

again, sorry.


-----Original Message-----
From: Paul Smith
To: 'log4j-dev@logging.apache.org'
Sent: 5/15/04 8:55 AM
Subject: RE: [VFS]: Integration - too early?

I assume you mean just log4j-dev? (I've removed commons-dev)>

Yes, I DEFINATELY WILL NOT break the log4j build. I spent quite a bit of
time last night thinking about just this.  I will (eventually) modify
Ant build so that VFS+dependancies are optional, and if not found,
and log4j will still compile.  It might be tricky, but that's the goal.

If I cannot get this to work, I will not commit it.  

I'm hoping that by creating a VFSPlugin in Chainsaw that can be
started, which uses reflection to see if VFS is available, and if not,
to start.  The VFSPlugin would be a GUI-plugin, so I think this would
I'll put this in a log4j.chainsaw.vfs package so it's easy to exclude.

Besides which I don't think I'll even have anything ready to check in
for a
week or 2.


-----Original Message-----
From: Shapira, Yoav
To: Jakarta Commons Developers List
Cc: Log4J Developers List
Sent: 5/14/04 11:04 PM
Subject: RE: [VFS]: Integration - too early?

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

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:imario@apache.org]
>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 inside it.  Now obviously I wouldn't have written a single line
>>commons code, and just wanted to make sure no-one can foresee a
>>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
>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
>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.
>    <provider
>        <scheme name="http"/>
>        <if-available
>    </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,
>>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?
>This brings me back to the previous question.
>Currently the SFTP provider reads the complete file into memory - i
>to check if this is still needet.
>But even if i change this - it is transparent to the above outlined
>>I assume if one has setup certificate-based authentication for a local
>with a remote
>>location, the password wouldn't even be needed here.  Would that work?
>>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
>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 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
>>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
>complete custom loggin solution to commons-logging with log4j as
>Keep on going !!!
>-- Mario
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message