Some thoughts on Chainsaw

[Mark Womack <mw...@bevocal.com>]

Since it looks that Chainsaw will become part of the log4j project, now
might be a good time for some discussion on what we would like to see from a
logging event viewer tool like Chainsaw.  I recently reviewed both Chainsaw
and Lumbermill, and was impressed with both of them.  I ended up choosing
Chainsaw over Lumbermill because of better filtering capabilities.  However,
neither of them completely addressed what I felt I needed.  So, here are my
thoughts.  Some of these I have bounced off Oliver in the past, and he was
open to them.  I would be interested it hear what others think.

1) Just as log4j allows for ultimate flexibility to configure the logging
setup on event sources, the viewer client should allow for ultimate
flexibility in viewing and filtering of the events.  This is an overall
principle to my suggestions.  The design of the tool should allow developers
to configure to their needs it using existing classes but it should also
allow for developers to implement their own classes they can plug into the
tool.  Just as log4j developers can now use any appender that ships with
log4j or, if none of them meet their needs, they can sit down and write
their own.  There should be equivalents in the the viewer tool.

2) Specific to the above, Chainsaw currently has a LoggingReceiver class
which is used to receive the logging events from the event source.  This
class is implemented to really only support SocketAppender event sources.
This is a prime candidate for an interface/base class which would allow
developers to write receivers to accept events from other types of sources.
One example is the ServerSocketAppender I recently submitted to log4j, but
even something like JMSAppender is not supported either.  For any type of
appender someone can write, they should also be able to write an equivalent
LoggingReceiver.

3) The viewer tool should support receiving logging events from multiple
sources.  Currently, Chainsaw only supports setting up one LoggingReceiver,
but (I believe) this is just a configuration limitation, not an actual
limitation.  If there were a way to specify it from the gui, it could easily
support multiple sources.  The messages would be interleaved in the table
listing of the events, so displaying the event source would be needed.
Supporting this will allow the debugging of applications that span multiple
machines/processes, which are quite common in the world of web applications
nowadays.  Parallel to this is the ability to add/delete sources
dynamically, probably via some gui.

4) The gui of the viewer tool should support a high degree of
configurability.  For the table list, what columns get displayed, how the
rows are sorted, etc.  The developer should be able to configure this, or
better yet be able to write their own viewer class.  Same with viewing each
individual event.  What event information is displayed and how it is
displayed should be configurable.

5) A minor item: I think that some sort of optional tool "status" pane,
where debug messages related to the tool get printed, will be needed at some
point.  For example, if the connection to an event source gets dropped, it
would be useful to know this.  Such a message could be printed to this area.

I'm sure there is much more that can be done to create the best
viewer/client tool for log4j, and I hope to contribute to this cause in the
future.  I would like to hear the thoughts others have on this topic.

thanks,
-Mark

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Some thoughts on Chainsaw

[Gary Udstrand <gb...@completeis.com>]

    I have written a UDPMulticastAppender and integrated it into chainsaw
for just this purpose.   We have our dev/qa/vend/prod servers all
broadcasting to separate multicast addresses.  We are using nested
diagnostic contexts to tie the transactions back to a specific server (this
is in a multi-node WLS 6.1 environment).

    I have also modified Chainsaw to listen for UDP traffic.  The port and
multicast address can be configured from the client allowing us to
selectively monitor different environments.  The advantage to this
arrangement is that not only can multiple clients monitor the log traffic,
multiple clients can monitor traffic from multiple servers.  Since it is
multicast it is also much less demanding on the network infrastructure,
which is important since bandwidth is always limited.

-Gary


----- Original Message -----
From: "Mark Womack" <mw...@bevocal.com>
To: "Log4j-Dev (E-mail)" <lo...@jakarta.apache.org>
Sent: Thursday, March 21, 2002 12:18 PM
Subject: Some thoughts on Chainsaw
>
> 3) The viewer tool should support receiving logging events from multiple
> sources.  Currently, Chainsaw only supports setting up one
LoggingReceiver,
> but (I believe) this is just a configuration limitation, not an actual
> limitation.  If there were a way to specify it from the gui, it could
easily
> support multiple sources.  The messages would be interleaved in the table
> listing of the events, so displaying the event source would be needed.
> Supporting this will allow the debugging of applications that span
multiple
> machines/processes, which are quite common in the world of web
applications
> nowadays.  Parallel to this is the ability to add/delete sources
> dynamically, probably via some gui.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>