Brad, I have to say that I like the way LF5 just focuses on being a monitor/viewer and delegates the receiving of the logging events up to something else. And it ties into the event stream in a very appropriate way, using log4j itself. It has sparked some thoughts in my head, that I am going to propose in another email message soon.
-Mark > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 27, 2002 10:40 AM > To: Log4J Developers List > Subject: Re: LF5 Questions > > > > Hi Mark, > > I apologize. I think I promised you a nickel tour of LF5 a while back. > Looks like you've dung into it yourself. Regarding your > investigations and > questions... > > >I started looking at the LF5 code, trying to familiarize myself with what > I > >might need to do to integrate SocketHubAppender support. It took me a > while > >to figure out that there is an LF5Appender that is used to post > the events > >to the LogBrokerMonitor instance. It took me even longer to realize that > >there is no direct support for SocketAppender in LF5. Instead it looks > like > >one is supposed to run a SocketServer that uses LF5Appender. I am > guessing > >that when I do this, a LF5 window will appear (being > automatically created > >by the LF5Appender)? That is rather clever if I understand this right. > > Correct! LF5 is strictly a visual Appender. The basis behind the product > was to give users an alternative destination (specifically a GUI ) for > logging events. The LF5Appender was designed to plug into Log4j > (much like > all of the other appenders) and create and instance of the > LogBrokerMonitor > to display the log records. Once that was working, we started adding > functionality to manage the log records (Priority level > filtering, Category > Tree Navigation, text searching, etc.). > > In the second release we added a series of new features including giving > users the ability to load log files from a file or URL and having the > ability to start up the LF5 GUI on its own (i.e. independent of > any running > applications). This meant that administrators could monitor their > application's log messages remotely. Other features included having the > ability to save configuration parameters and storing Most > Recently Used log > files in a list for quick access. > > The final release (added just before the product was donated to Apache) > included an NDC filter and Priority level color configuration. > > LF5 is a pretty dumb beast. All it does is display and manage > log records > (and that's its intent). You are correct that LF5 has no direct support > for Socket Appenders( or any other appenders for that matter). However, > since the SocketAppender can register another Appender to handle > the output > of log records, LF5 can plug in to it and receive any message being sent > over a socket. > > >So, are there any recommendations on how to go about adding support for > >SocketHubAppender? What if I wanted to connect a JMSAppender? > > No. If I understand the purpose of the SocketHubAppender, there > is no need > to add support to LF5. If events are being sent to the SocketHubAppender > and then passed on to all log servers connected to the SocketHubAppender, > then presumably each of the log servers has an Appender registered with it > to handle the display of these events. If that is the case, then LF5 can > be registered as the Appender. Or, if a RollingFileAppender is used, LF5 > could open each of the log files either locally on each server or remotely > from one server. > > >What if I wanted to connect a JMSAppender? > > We had actually talked about adding this functionality in but held off > doing so in lieu of getting some higher priority features added. > > >What if I wanted to support different types of appenders all appending to > the same LF5 > >window? > > I'm not sure you want to be using LF5 this way. It is an Appender itself. > > Hope this helps, > > Brad > > > Brad Marlborough > ThoughtWorks, Inc. -- The art of heavy lifting(SM) > http://www.thoughtworks.com > > > > > <[EMAIL PROTECTED] > > rg> To: "Log4J > Developers List" <[EMAIL PROTECTED]> > cc: > > 06/26/2002 10:44 Subject: LF5 > Questions > PM > > Please respond to > > "Log4J Developers > > List" > > > > > > > > > > > > > For Chainsaw, I took the approach of defining different types of > receivers, > since Chainsaw acts like a SocketServer and directly integrates the > receiving of the logging events (it does not use an appender). > > I wonder if there is not an opportunity to create a new class of object in > log4j? Maybe create a Receiver class that would receive remote logging > events and direct them into the "local" log environment, similar to > SocketServer. But, they could be created or configured as log4j objects. > > I'll have to think about it some more, but I would like to hear > from others > about how to go about this. > > -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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
