Gary, You have mentioned this appender earlier. If you want to, it would be interesting to look at and maybe contribute to log4j? It sounds like a very useful and interesting implementation.
So, do you think the thoughts on Chainsaw would fit into how you implemented your changes? If there were an architecture in place (ie LoggingReceiver interface/base class), you could create classes to plug in your UDPMulitcast stuff. What kind of changes did you need to make in Chainsaw to support your code? One item I did not go into detail about is that these pluggable modules will probably need some supporting gui. For example, to support receiving messages from my SocketServerAppender in Chainsaw I had to add a dialog to allow the user to enter the host and port to connect to. I imagine that other appender types will need to have their own specific gui (JMS topic, port/multicast address, etc). It seems to me there are 2 requirements for this: 1) The viewer tool needs to be configurable to define the set of logging receivers it will bring into its gui. Or, it could implement some kind of discovery mechanism that searches the classpath for classes that implement a known interface. Either way it gets a list of logging receivers to integrate into its gui. 2) When the user chooses the appropriate gui widget (a menu item?), the viewer tool calls a predetermined method on the reciever class to display the receiver's gui. just some more thoughts, -Mark -----Original Message----- From: Gary Udstrand [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 1:07 PM To: Log4J Developers List Subject: Re: Some thoughts on Chainsaw 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" <[EMAIL PROTECTED]> To: "Log4j-Dev (E-mail)" <[EMAIL PROTECTED]> 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
