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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
