Asp Forum - rlogview, chainsaw, and log4r

List Recv

6/30/2006 9:54:00 PM

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... 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/cha...

7 Answers

scott

7/1/2006 5:58:00 PM

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... 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/cha...

List Recv

7/2/2006 7:08:00 PM

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... 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/cha...

List Recv

7/2/2006 7:09:00 PM

scott wrote:
> Log4net, log4php, log4perl and log4cxx frameworks can all send events
> to Chainsaw over UDP or TCP

Hmm.... sounds like this would be a good feature for log4r to add as
well, no?

scott

7/3/2006 5:46:00 AM

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/...)

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... 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/cha...

List Recv

7/4/2006 3:19:00 AM

Thank you very much for the detailed info!

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/...)
>
> 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... 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/cha...

List Recv

7/16/2006 7:00:00 PM

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/...)
>
> 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... 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/cha...

scott

7/23/2006 5:49:00 PM

Yes...see the 'view example receiver configuration' button on the
Welcome tab.

Save that to your local file system (or a web server) and modify it as
needed.

Next, go to the view-show application wide preferences menu
In the automatic configuration URL field at the bottom of the page,
enter the URL to the config file (for example:
file:///c:/chainsaw-config.xml)

Restart Chainsaw

It'll load each 'plugin' entry in the config file as a receiver config.
If there are errors configuring the receiver, you'll see messages in
the chainsaw-log tab.

Good luck!

listrecv@gmail.com wrote:
> 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/...)
> >
> > 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... 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/cha...

comp.lang.ruby

rlogview, chainsaw, and log4r

List Recv

scott

List Recv

List Recv

scott

List Recv

List Recv

scott

x Login to ForumsZone