On Feb 22, 2005, at 11:18 PM, Paul Smith wrote:
Good point. I personally wonder why projects _need_ to move to Subversion. Some of the IDE based tools for SVN don't appear to be as mature as I would like, but as an upgrade junkie, it's always nice to try something new. I'll leave that sort of decision to the group as a whole (although I think all Apache projects are supposed to be in SVN by the end of the year??)Chainsaw is getting big. What does everyone think about moving Chainsaw out into it's own CVS module and making it a 'client' of the log4j library?
If you were going to consider that, you should also consider moving Chainsaw to Subversion and spinning Chainsaw off as a distinct subproject of the Logging Services project. I'm not suggesting that you do, just that all the options should be considered.
I didn't know about the forced migration, however that might be true. The Jakarta Wiki describes their migration as an "infrastructure desired event". If there is a Subversion migration in our future, then it might be best to try to get all the version control pain over in one shot.
Curt, do you think breaking Chainsaw out of the current logging-log4j module is a good/bad idea?
It probably is a good thing and probably a good thing to spin it off as a subproject. Chainsaw might be better off having independent releases that aren't tightly coupled to log4j's release schedule. However, that is just speculation on my part.
* VFS[3] - Chainsaw could be _way_ more useful if JSch can be used with VFS - browse any VFS filestore, including SFTP, so one could access log files from a protected/remote store. Recently JSch moved from a LGPL license to BSD, so this should be ok to embed[2]
I'm unclear on the relationship between VFS and JSch. Does VFS depend on JSch to access SFTP? Would Chainsaw use JSch directly?
I would see Chainsaw depending on VFS, which then uses JSch to implement the SSH stuff. From Chainsaw's perspective, it only knows about VFS. Chainsaw would not need to know about JSch, but would effectively require JSch for ssh/sftp functionality.
If Chainsaw was going to depend on it, then it might be good to get it out of the Jakarta Commons sandbox.
* Lucene[4] - Be able to index and 'google' log files. I've been playing in this area and searching is FAST. I'm fiddling around to see how conceptually useful it is to create a Lucene index of sets of log files, and be able to easily and quickly locate logging information. At the moment it's the indexing speed that's not as fast as I would like (minutes for a 40meg log file), but I'm thinking through some other options that could speed that process up considerably.
Are you suggesting using Lucene within Chainsaw or are you suggesting providing DocumentAnalyzers so that Lucene installations can make better sense of log files? If it is adding DocumentAnalyzer's in Lucene, it would probably be simpler to make it part of Lucene.
Using Lucene within Chainsaw. One does need to have a LoggingEvent-> Lucene Document converter, and that could in theory be in Lucene, but I think it makes more sense to be in log4j. Anyway, I'm still not totally convinced that creating an index on logging files is any better than simply using grep, but Lucene may be useful.
It might be good to abstract out the concept of a metadata service. For example, if you were running on Mac OS/X Tiger, it would be a better user experience to use the Spotlight metadata services (http://developer.apple.com/macosx/tiger/spotlight.html). Likewise on Windows, it may be better to use the Indexing Service (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ indexsrv/html/indexingservicestartpage_6td1.asp). Both of those would likely require some native code (both to scan the documents and access the API).
Does anyone know of the compatibility with the Apple Public Source License and Apache? INAL, but given that one has to register to get the source, I start to doubt whether it's going to be compatibile, but worth looking at. Should I email [EMAIL PROTECTED]* ZeroConf (aka Rendevouz) - This relies on the LGPL licensed JmDNS[5] library. I have successfully created some code that automatically discovers SocketHubAppenders located on the network. I foresee a vastly simpler user experience if log4j-enabled applications using Appenders with matching Receivers could broadcast their settings via zeroconf. Within Chainsaw the user could then double click the discovered appender, and Chainsaw could read/parse and create matching Receivers to connect to those appenders. No more XML configs, no more rather lame Receiver creation dialogs. Since this is LGPL licensed, I've started making this as a Plugin (both log4j, and for Chainsaw). I've also emailed the developers to ask if they would consider dual licensing it for Apache, but have heard no reponse at this stage. If there is an Apache-friendly license that does the same thing, please let me know.
Apple appears to have a Java implementation (http://developer.apple.com/darwin/projects/rendezvous/) available under the Apple Public Source License (http://developer.apple.com/darwin/licensing.html). However, there seems to be a problem with the site at the moment that prevents viewing the license.
Again might be an area to allow multiple implementations.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
