It sounds like a good proposal. The only question I have is that I get a lot of requests for Chainsaw to include the originating host for each logged message. Using the current approach by Chainsaw I can modify the receiver to include this information. This scenario would not be handled by the proposal. Personally this is not a problem, but something to be aware of.
Oliver > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, 28 June 2002 14:41 > To: Log4J Developers List > Subject: Receiver Proposal > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
