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
