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 Sat, 15 May 2004 03:13:29 GMT
I'm hoping that there will be an official release soon.  It's a nice
package, maybe they keep thinking of new things to add...

-----Original Message-----
From: Jacob Kjome
To: Log4J Developers List
Sent: 5/15/04 1:07 PM
Subject: RE: [VFS]: Integration - too early?

So, is commons-vfs ever going to have an official release?  There are
CVS 
daily snapshots, but no official release that I am aware of.  Maybe you
can 
convince the commons-vfs team to do this?  I use it in my build files to
do 
automatic downloading of dependencies.  I like it because it deals with
all 
protocols, not just http like <get> which comes with Ant, although I do
use 
<get> to bootstrap the build.  Have to get commons-vfs and its
dependencies 
before I can use it in the build (at least if I don't want to have to
force 
people to put it in ANT_HOME/lib or user.home/.ant/lib).

Jake

At 09:10 AM 5/15/2004 +1000, you wrote:
>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.
>
>Paul
>
>-----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
>the
>Ant build so that VFS+dependancies are optional, and if not found,
>Chainsaw
>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
>optionally
>started, which uses reflection to see if VFS is available, and if not,
>fails
>to start.  The VFSPlugin would be a GUI-plugin, so I think this would
>work.
>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.
>
>cheers,
>
>Paul
>-----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?
>
>
>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: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
> >psmith@apache.org
> >>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: 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


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


Mime
View raw message