Thanks for the comments..

We'll be working on documentation shortly.  In the meantime, here is some information 
that may help:

- The default application-wide 'tab identifier' is currently "PROP.hostname - 
PROP.application" - meaning if 'hostname' and 'application' properties exist for the 
event (most network appenders on the CVS tip apply this property), the values are 
resolved and events are routed to the matching tab, or a tab is created.  You can 
change this identifier while Chainsaw is running and new events will route to the 
changed expression.  

- This identifier is configurable in the 'view, show application-wide preferences' 
menu.  To see what keywords are supported, here is a link to the latest resolver class 
(read over the javadoc): 
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/spi/LoggingEventFieldResolver.java?rev=1.4&view=auto

- As an example of seeing all events, regardless of source, in the same tab, I changed 
the identifier to the text ALL, and since all events match, they are added to the 
single 'all' tab.

- I just added LogFilePatternReceiver - which parses non-xml log files.  There are a 
few caveats but it works really well.  See the documentation for how to configure the 
receiver's parsing pattern here: 
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/log4j/varia/LogFilePatternReceiver.java?rev=1.3&view=auto

- There are a number of features that should still be implemented prior to release
  * individual tab settings are saved across a few files - including 
    serialized java files - and we should move this to an XML format prior 
    to release)
  * General UI tweaks
  * More settings need saved on exit
  * I just committed support for expression-based searching, but I still 
    want to add reverse-search
  * Implement ruleset support for color filtering (only a single ruleset 
    is saved currently per tab)
  * We were thinking about adding the ability to dynamically define a 
    tab expression (specify the tab name and expression, and all 
    existing matching events as well as new events which match would route 
    to this newly defined tab) - currently only one tab may display an event -
    this change would make each view dynamic, so the event may be displayed on 
    any number of tabs, based on the defined expressions and the default 
    tab identifier

- We would be happy to review any bug patches you are interested in providing

- I don't think the LogFilePatternReceiver can 'tail' - I haven't tried it but it 
should be relatively easy to add

- We will be looking into improving the detail pane - XML as well as exceptions should 
format in an easily readable way

Hope this helps,
Scott


-----Original Message-----
From:   Finch, Sam [mailto:[EMAIL PROTECTED]
Sent:   Tue 3/16/2004 4:51 AM
To:     'Log4J Developers List'
Cc:     
Subject:        Evaluating Chainsaw 2.0 - Questions
Hi

I am evaluating Chainsaw 2.0 as a possible future substitute for Unix tools
(grep, tail etc).

General points
- It would be helpful to be able to coalesce multiple log files into one
'virtual view', ie. I want to filter on logger x across n logfiles.  Sorry
for going all 'user' on you but it would be a nice feecha.  ;)
- I understand why Chainsaw requires XMLLayout (PatternLayout is v. tricky
to parse), but it seems to generate vastly larger files (up to 10X) under
some circumstances.  Does anyone have experience / opinion of this problem?
- How is the software progressing towards release?
- Do the developers have the time to entertain / review / include bug
patches?

Monitoring
It may be the case that I am mischaracterising Chainsaw as an application
monitoring tool when it is really a logfile reader.  We are using JMX and
this might be a better avenue for error notification though its integration
with L4J needs some work.

- The software does not seem able to monitor a logfile (tail -f style) as it
is written.  Is this likely to become a feature or should I be using
receivers for this?
- We are currently using the SMTPAppender for remote notification of ERRORs
under some circumstances.  I am dubious about using receivers instead as
they do not seem to offer a similar guarantee of delivery (eg, if Chainsaw
is not running).  Is this reasonable?

Bugs / defects (hopefully helpful!)
- The pattern editor window should probably not offer a constantly updating
preview as this tends to get lagged, and can crash / fail to respond / fail
to reappear if the event queue gets too long.
- It doesn't seem possible to persuade the layout window to display
exceptions over multiple lines (eg, using <pre>).  Whole exceptions get
displayed on one line which is a pain.
- The menus tend to appear in the middle of the window rather than at the
top.

Chainsaw is already looking like a really useful utility and I definitely
hope to be using it in production at some stage this year.

Thanks in advance for any pointers.

Sam


http://www.espeed.co.uk
CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are 
confidential. If you are not the named recipient please notify the sender and 
immediately delete it. You may not disseminate, distribute, or forward this e-mail 
message or disclose its contents to anybody else. Copyright and any other intellectual 
property rights in its contents are the sole property of eSpeed, Inc and its 
affiliates.

This e-mail was issued by eSpeed International Limited ("eSpeed").  eSpeed is a 
limited liability company incorporated under the laws of England (company number 
3809189 and VAT registration number 577 406809).  eSpeed's registered office is at One 
America Square, London EC3N 2LS.  For any issues arising from this email please reply 
to the sender.

E-mail transmission cannot be guaranteed to be secure or error-free. The sender 
therefore does not accept liability for any errors or omissions in the contents of 
this message which arise as a result of e-mail transmission.  If verification is 
required please request a hard-copy version.

Although we routinely screen for viruses, addressees should check this e-mail and any 
attachments for viruses. We make no representation or warranty as to the absence of 
viruses in this e-mail or any attachments. Please note that to ensure regulatory 
compliance and for the protection of our customers and business, we may monitor and 
read e-mails sent to and from our server(s). 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




<<winmail.dat>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to