> It's not so wacky. For log4j v1.3 I am adding "receivers". > Receivers are > the opposite of appenders in that they can be configured to "receive" > remote/eternal events. They can be configured as part of a logger > repository, same as loggers and appenders. Once the receiver > has an event, > it "posts" it to the logger repository where it gets handled by the > configured appenders as if the event had been generated > locally. So, it can > be written to the console, written to a file, etc. v1.3 is > going to have a > SocketReceiver (matching SocketAppender), SocketHubReceiver (matching > SocketHubAppender), JMSReceiver (matching JMSAppender), and > maybe more as > makes sense.
That's very much what I was thinking, but I hadn't thought about the even more generic case of a Receiver, which you have. Wow, that is cool. > types. Recievers make this possible. Chainsaw does not need any > appender/receiver specific code. As new receiver classes are written, > Chainsaw should be able to take immediate advantage of them with no > modification. Just configure it to use them via a (yet to be > designed) > plugin gui or a configuration file. I like it. > Also, Chainsaw should be > modified to be > like LF5 in that the events displayed should be processed by > a Chainsaw > appender. That's a good refactor of the concept of the internal Processor object, would make TableModel code lighter weight, encapsulate the updating of the model into a separate class. > Does that make sense? I can't wait to see some of these > changes folks are > talking about. I want to get my hands dirty too. Me too. I am too afraid to start anything until some of the changes are committed. Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
