One more clarification: Chainsaw V2 uses log4j 1.3alpha internally because of log4j 1.3's support of receivers and new methods on LoggingEvent.
Chainsaw V2 can process events generated by -any- of the log4j 1.2 appenders, minus the limitations Paul mentioned re: serial incompatibility of LocationInfo and possibly MDC for log4j 1.2 SocketAppender. Just wanted to make sure folks understood Chainsaw's log4j 1.3 dependencies are all internal, and you can use log4j 1.2 to generate events which can be processed in Chainsaw. Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -----Original Message----- From: Jess Holle [mailto:[EMAIL PROTECTED] Sent: Wed 4/4/2007 1:29 PM To: Log4J Developers List Subject: Re: 1.3 - A Line in the Sand Ceki Gülcü wrote: >> I'd be keen to consider starting Chainsaw v3 from scratch along side >> any post-log4j1.3-type operation and build in exceptional support for >> enterprise log management, but I'm only one person, and I know many >> of us are incredibly busy, but we were so active there for a while I >> think of the potential of what we could achieve! :) From a Java >> point of view I think many of the Java 1.4+ network library, and >> java.util.concurrent stuff could be well used in a new logging package. > I would certainly be interested in Chainsaw v3. How about doing it in > logback? I'd really like to see a Chainsaw that: 1. Didn't use an alpha log4j library 2. Fully supported log4j output (i.e. socket appenders, log4j XML files, etc) 3. Gives first-class (native terminology) treatment to log4j log event fields (NDC, MDC, level, etc) If that's achieved via logback, I could actually care less. That said, I don't see using logback myself due to: 1. Use of String rather than Object messages * This allows messages to convey general structured data without having to hack some intervening string representation (e.g. for direct O-R mapping of structured log messages). 2. Overall apparent lack of attempt to maintain compatibility with log4j * I really want source and binary compatibility for the 90% "user code" case. * Beyond this, I have custom repository selectors, JMX MBeans that account for and handle multiple repositories, etc. o I'd give these up if the library fulfilled these roles completely adequately. The MBeans would actually be most difficult to give up as I really like mine :-) -- Jess Holle
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
