You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Paul Smith <ps...@apache.org> on 2005/02/23 03:44:24 UTC
Chainsaw as seperate CVS module?
Hey All,
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?
In Eclipse one can make a Project have a dependency on another project,
so that makes it nice from a developer point of view, and from an Ant
point of view we can just have Chainsaw require to be built against
specific log4j jars.
I have the following thoughts going through my mind at the moment that
would require add ingseveral jars to the dependencies of Chainsaw, and
it just might make everyones life easier if it were in a seperate
module. I'm not too fussed either way, but thought I would float the
idea in case people think it's a good idea.
Anyway, on to some ideas I've been having, comments appreciated:
* 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]
* 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.
* 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.
[1] - http://www.jcraft.com/jsch/
[2] - http://wiki.apache.org/old/Licensing
[3] - http://jakarta.apache.org/commons/sandbox/vfs/
[4] - http://lucene.apache.org/java/docs/index.html
[5] - http://jmdns.sourceforge.net/
regards,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw as seperate CVS module?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 03:44 AM 2/23/2005, Paul Smith wrote:
>Hey All,
>
>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?
>In Eclipse one can make a Project have a dependency on another project, so
>that makes it nice from a developer point of view, and from an Ant point
>of view we can just have Chainsaw require to be built against specific
>log4j jars.
>
>I have the following thoughts going through my mind at the moment that
>would require add ingseveral jars to the dependencies of Chainsaw, and it
>just might make everyones life easier if it were in a seperate
>module. I'm not too fussed either way, but thought I would float the idea
>in case people think it's a good idea.
+1
I think its a very good idea to have chainsaw its own CVS module (and move
to SVN later). Scott, what do you think?
Spawning Chainsaw as a separate project is also a possibility. If Chainsaw
is in its own module, a separate project could make sense.
>Paul Smith
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw as seperate CVS module?
Posted by Curt Arnold <ca...@houston.rr.com>.
On Feb 23, 2005, at 2:37 AM, Paul Smith wrote:
> Spotlight and Indexing service appear to be about finding the file
> that matches a query, IIRC. With Lucene there is more flexibility.
> Taking a classic Log file, I've created a lucene Document with 1 Field
> for each and every line of text in the log file. One can then perform
> queries on the index of the log file and get matching lines.
> In some ways this concept is completely reproducing something that a
> database would do, but for really large log files Lucene may be better
> suited. As I said, it's mostly conjecture on my part about how useful
> this is, it really is mostly an 'interesting' idea more than a
> practical at this stage (compared with the zeroconf and VFS idea).
>
Okay. I was guessing that you were looking at Lucene to locate log
files that matched a query and that only seemed to be useful if you
were dealing with rolling logs since otherwise you'd likely know what
file to look at.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Chainsaw as seperate CVS module?
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
> There has been so much conversion to subversion recently in other areas
> of Jakarta, and I'm sure I read an email somewhere that the goal was to
> have everyone over to SVN by the end of the year, but I wouldn't trust
> my memory on things...
You read correctly: Henri Yandell sent an email with the deadlines (1/1/2006
being the final cutover date) a few days ago on pmc@jakarta.
I don't think a move to a separate CVS module should be combined with a move
to SVN. As always, one step at a time is better. I do think a move to a
separate CVS module makes sense, just like it did for Jasper in the Tomcat
world and there are numerous other examples.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw as seperate CVS module?
Posted by Paul Smith <ps...@aconex.com>.
> 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.
>
There has been so much conversion to subversion recently in other areas
of Jakarta, and I'm sure I read an email somewhere that the goal was to
have everyone over to SVN by the end of the year, but I wouldn't trust
my memory on things...
>>
>
> If Chainsaw was going to depend on it, then it might be good to get
> it out of the Jakarta Commons sandbox.
True! I'll have a prod over on Jakarta Commons list to see where that's
at, because there's been a fair bit of work with it over the last few
months.
>
> 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).
>
Spotlight and Indexing service appear to be about finding the file that
matches a query, IIRC. With Lucene there is more flexibility. Taking a
classic Log file, I've created a lucene Document with 1 Field for each
and every line of text in the log file. One can then perform queries on
the index of the log file and get matching lines.
In some ways this concept is completely reproducing something that a
database would do, but for really large log files Lucene may be better
suited. As I said, it's mostly conjecture on my part about how useful
this is, it really is mostly an 'interesting' idea more than a practical
at this stage (compared with the zeroconf and VFS idea).
cheers,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw as seperate CVS module?
Posted by Curt Arnold <ca...@apache.org>.
On Feb 22, 2005, at 11:18 PM, Paul Smith wrote:
>
>>> 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.
>>
>>
> 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??)
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).
>
>>> * 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.
>>
>>
> 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 licensing@apache.org?
>
Again might be an area to allow multiple implementations.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw as seperate CVS module?
Posted by Paul Smith <ps...@aconex.com>.
>> 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.
>
>
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??)
Curt, do you think breaking Chainsaw out of the current logging-log4j
module is a good/bad idea?
>> * 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.
>>
>> * 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.
>> * 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.
>
>
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 licensing@apache.org?
Thanks for your response.
cheers,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw as seperate CVS module?
Posted by Curt Arnold <ca...@apache.org>.
On Feb 22, 2005, at 8:44 PM, Paul Smith wrote:
> Hey All,
>
> 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.
> In Eclipse one can make a Project have a dependency on another
> project, so that makes it nice from a developer point of view, and
> from an Ant point of view we can just have Chainsaw require to be
> built against specific log4j jars.
>
> I have the following thoughts going through my mind at the moment that
> would require add ingseveral jars to the dependencies of Chainsaw, and
> it just might make everyones life easier if it were in a seperate
> module. I'm not too fussed either way, but thought I would float the
> idea in case people think it's a good idea.
>
> Anyway, on to some ideas I've been having, comments appreciated:
>
> * 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?
>
> * 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.
> * 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Chainsaw as seperate CVS module?
Posted by Mark Womack <wo...@adobe.com>.
Since the message was not prefaced with "[VOTE]" I figured this was more a
matter of opinion than one of actual voting/deciding. And Paul has
subsequently called an official vote.
If any logging services project wants to move to SVN ahead of a coordinated
effort, who am I to stop them?
And I am willing to coordinate the effort to switch to SVN for all of
logging services, but I have to finish my other log4j tasks first. We can
continue the discussion on logging-general.
-Mark
> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch]
> Sent: Wednesday, February 23, 2005 9:54 AM
> To: Log4J Developers List; 'Log4J Developers List'
> Subject: RE: Chainsaw as seperate CVS module?
>
> At 05:51 PM 2/23/2005, Mark Womack wrote:
>
> >-1 on doing it in Subversion, for now. I think we need to look at the
> SVN
> >issue as a whole for all of the Logging Services projects and coordinate
> the
> >jump.
>
> Mar, do you really mean to veto the creation of the chainsaw module in
> SVN?
> Although I also (much) prefer to see new module created in CVS, if the
> people who are going to do the work prefer SVN, the decision should be
> left
> to them.
>
> Casting a veto is a pretty serious thing. In some projects, they are cast
> left and right -- as a result their communities tend to dwindle over time.
> (I prefer not to give names or point fingers.)
>
> >-Mark
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> 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
RE: Chainsaw as seperate CVS module?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 05:51 PM 2/23/2005, Mark Womack wrote:
>-1 on doing it in Subversion, for now. I think we need to look at the SVN
>issue as a whole for all of the Logging Services projects and coordinate the
>jump.
Mar, do you really mean to veto the creation of the chainsaw module in SVN?
Although I also (much) prefer to see new module created in CVS, if the
people who are going to do the work prefer SVN, the decision should be left
to them.
Casting a veto is a pretty serious thing. In some projects, they are cast
left and right -- as a result their communities tend to dwindle over time.
(I prefer not to give names or point fingers.)
>-Mark
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Chainsaw as seperate CVS module?
Posted by Mark Womack <wo...@adobe.com>.
> -----Original Message-----
> From: Paul Smith [mailto:psmith@apache.org]
> Sent: Tuesday, February 22, 2005 6:44 PM
> To: log4j-dev@logging.apache.org
> Subject: Chainsaw as seperate CVS module?
>
> Hey All,
>
> 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?
>
> In Eclipse one can make a Project have a dependency on another project,
> so that makes it nice from a developer point of view, and from an Ant
> point of view we can just have Chainsaw require to be built against
> specific log4j jars.
+1 on a separate CVS module.
-1 on doing it in Subversion, for now. I think we need to look at the SVN
issue as a whole for all of the Logging Services projects and coordinate the
jump.
+1 on Chainsaw becoming a subproject of Logging Services. I share Scott's
reservations about there being a large enough community. But I do like the
idea from the sense that Chainsaw is a tool that can be used across all of
the LS logging projects, and being an official subproject will emphasize and
foster that. From Paul's email it is obvious that there are a lot of great
ideas for Chainsaw. So, if more folks can get involved and excited about
it, I would really like to see this happen.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org