Sparked by my recent modification of Chainsaw and my wanderings through the LF5 code, I am going to make the following proposal. Please comment as you see fit.
The proposal: Just as log4j has support for Appender classes, of which custom versions any developer can create, how about a Receiver class? Receiver classes would be instantiated and attached to logging repositories, just as Appenders. They would be named and configurable via a configuration file, just as Appenders. As its name indicates, a Receiver would receive events (most likely from a remote source), but instead of appending them as an appender does, it would post the events to the repository as if the event had been generated locally. This behavior would be like the current SocketServer/SocketNode/JMSSink. What does this buy us? 1) When I write an appender, I could write a matching receiver. This receiver would be automatically usuable within the log4j framework. No more SocketServer/SocketNode/JMSSink classes that need to get executed outside of log4j and that users can't figure out how to configure and run without extra effort. Instead, we would create SocketReceiver, SocketHubReceiver, and JMSReceiver. You could run some really basic main application that loads a configuration file with any of these receivers configured and you are done. The configuration would be no harder than any other type of configuration 2) Riding on #1, it will be easy to write your own custom remote event logging server. Just configure some basic code to use a configuration file with receivers defined. Since receivers will be associated with a repository, you can attach different appenders to the same repository and have it do whatever you want with the received events. You could even get fancy and create a useful Swing gui to configure things via an window. 3) Log event viewers/clients, like Chainsaw and LF5, would be able to start receiving events from new types of appenders/receivers automatically, no modifications required. Just hook the matching receiver into the configuration and you are done. (This assumes that a ChainsawAppender would be created, similar to the LF5Appender) This becomes the standard way to hook any new viewer/client into log4j. Why can't you just write a special Appender that does what you want? Appenders are really designed to send logging events outside of the log4j environment (file, smtp, telnet, jdbc, you name it). You could write an appender that received events and posted them to the local log4j environment. But then it would need to have empty append()/doAppend() methods that do nothing since you wouldn't want them to deal with the same event twice. It would be a very obvious hack. Better to make the Receiver concept a first class logj citizen and class. Just as appenders send events outside the log4j environment, receivers would bring events inside the log4j environment. That's it for now. Comments? -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
