Is there anyway to save those receivers in chainsaw, so that when I
exit, I don't need to reconfigure it?



scott wrote:
> The simplest way to send events from log4r to Chainsaw is to configure
> log4r to use a FileOutputter with a PatternFormatter.
>
> On the Chainsaw side, you'd then set up a LogFilePatternReceiver to
> read the log file.
>
> Log4r side:
>
> You could use a pattern format like:
> [%l] %d - %m
>
> which creates events that look like this:
> [DEBUG] 2001-01-12 13:15:50 - message here
>
> Chainsaw side:
>
> Define a logFilePatternReceiver (see an example receiver config from
> the Welcome tab).
>
> The receiver's logFormat matching the above format would be:
> [LEVEL] TIMESTAMP - MESSAGE
>
> The receiver's timestampFormat would be:
> yyyy-MM-dd HH:mm:ss
>
> You'll also need to specify a fileURL for the receiver - something like
> file:///c:/logfile.txt
>
> By the way, there's also a version of LogFilePatternReceiver can that
> read events over ssh (VFSLogFilePatternReceiver in the
> org.apache.log4j.chainsaw.varia package).  Same arguments, but the
> fileURL can be any URL supported by the jakarta commons-VFS project
> (http://jakarta.apache.org/commons/vfs/index.html)
>
> As for TCP/UDP integration, it depends on what you need.  The other
> frameworks generate XML events conforming to log4j's dtd.
>
> The xml-supporting network receivers require the appender (outputter)
> side to send events to a multicast address or the IP of the box running
> Chainsaw itself.
>
> Log4j also provides a 'sockethubappender' that allows a Chainsaw client
> (socketHubReceiver) to connect to a source (socketHubAppender) and the
> appender will push events to the receiver (reverse-connect of
> SocketAppender/SocketReciever), but there isn't an xml-supporting
> version of that appender like there is for the socketapppender that has
> the source send events to the Chainsaw client.  This would be more
> useful in a long-running server environment, and in some cases where
> firewall issues arise.
>
> Do you need to receive all events?  If so, UDP and multicast are out.
> Also, since TCP sockets can block, I usually suggest just using the
> LogFilePatternReceiver or VFSLogFilePatternReceiver if you need to
> receive all events.  Storing events in a database and using
> CustomSQLDBReceiver is also an ok option if your environment can handle
> the processing load.
>
> If you can lose events, UDP and multicastappenders are good options,
> assuming your network config can support it.
>
> Scott
>
> listrecv / gmail.com wrote:
> > That's a very useful idea.  What do you recommend to be the simplest
> > way to hook up log4r to Chainsaw, then?
> >
> > scott wrote:
> > > In case you didn't know, Chainsaw provides a few receivers that allow
> > > it to process events from other frameworks.  You can find examples of
> > > these receiver configurations from Chainsaw's Welcome tab (view example
> > > receiver configuration).
> > >
> > > Process regular text log files: LogFilePatternReceiver
> > > Accept xml-formatted events sent via tcp socket: XMLSocketReceiver
> > > Accept xml-formatted events sent via UDP: UDPReceiver (or
> > > MulticastReceiver)
> > > Process events stored in a database: CustomSQLDBReceiver
> > >
> > > Log4net, log4php, log4perl and log4cxx frameworks can all send events
> > > to Chainsaw over UDP or TCP (and if folks using those frameworks are
> > > just generating log files, they can use LogFilePatternReceiver).
> > >
> > > Hope this helps,
> > >
> > > Scott
> > >
> > > listrecv / gmail.com wrote:
> > > > log4j has a great hierarchial viewer called chainsaw.  When you're
> > > > working on a large app, it makes things *much* easier - you can drill
> > > > down as you need to in the logs (easier than running grep over and
> > > > over).
> > > >
> > > > log4r doesn't have one.  I found a link
> > > > http://sourceforge.net/projects/rlogview/ to rlogview, but it's several
> > > > years old, seems to rely on deprecated gtk libs, and wouldn't run (at
> > > > least on my windows machine).
> > > >
> > > > It's only about 200 lines of code.  Are there any GTK mavens here who
> > > > could fix it, or write a new one?  It would be a great asset to the
> > > > Ruby community.
> > > > 
> > > > http://logging.apache.org/log4j/docs/chainsaw.html