I agree that LoggingEvent should be serial-compatible with previous versions (1.2.7/8 at a minimum).
If Chainsaw were to have its own release cycle, we would release a lot more often than log4j and also plan releases to coincide with log4j's releases. As discussed previously, at this point I'd prefer that Chainsaw stay as a part of the log4j project - primarily because the size of the developer community is not growing (it's been 2 with a few patches from others since it's inception). I gave the 'category' -> 'logger' DTD example primarily to show how the DTD changed when jdk 1.4 util.logging was released and log4j renamed major pieces of their system in order to have names match. There's no technical reason we couldn't support the prior DTD in XMLDecoder, but I've only seen one person mention this bug and they were fine with updating their log4j version to a more recent release in order to avoid the problem. Scott -----Original Message----- From: Curt Arnold [mailto:[EMAIL PROTECTED] Sent: Tue 5/3/2005 10:49 PM To: Log4J Developers List Cc: Subject: Re: Reconsideration of features for 1.3 (Re: slf4j and log4j) 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]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
