On May 3, 2005, at 11:17 PM, Scott Deboy wrote:
Chainsaw V2 has too many dependencies on new (1.3) features to be incorporated into a 1.2.x release without major rework (relies on new LoggingEvent constructors, receivers, etc.). It's also available via WebStart, so there is no real value in working to include it in a 1.2.x release.
Chainsaw can process events from any logging framework that can write a file to disk in a fixed format (using LogFilePatternReceiver), can read events out of a database, etc. The only log4j 1.2.x-specific capability is related to Chainsaw's ability to deserialize LoggingEvents generated by older versions of SocketAppender.
Chainsaw should be able to process files saved using 1.2.x XMLLayout - Chainsaw expects 'logger' and not 'category' for the name of the logger node, but this changed in Oct 2002. Versions of log4j prior to Oct 2002, which used XMLLayout to create files, would not be able to be processed.
Properties were the only feature added to the XML with log4j 1.3 (if I remember correctly), and they are optional.
We left Chainsaw in a little bit of limbo with its own CVS module, but not as formal subproject of Logging Services. I'm thinking that it might be best if Chainsaw had its own release cycle and would incorporate log4j classes in its jar file instead of assuming that it would be paired with a particular log4j.jar. Assuming that we can get the serialized forms compatible, it shouldn't matter is your app using 1.2.x is being monitored by Chainsaw or Chainsaw 2.
Is there any reason it would be difficult for Chainsaw to process both "logger" and "category" as equivalent in XML files? I can take a look unless there is a reason not to.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
