What does this buy us? continued... 4) If designed with a proper extendable design, the Receiver class could be used to bring other types of logging messages into the log4j environment. I know that support for other logging packages is a non-goal in general, but the Reciever class would make it easy for developers to handle these cases if they need to. It should be relatively simple to create a JDKLoggingReciever that would get messages for the jdk logging package and then "translate" them into the log4j environment. Other logging packages or other sources could be handled in a similar way.
-Mark > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 27, 2002 9:41 PM > 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]>
