logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Deboy" <sde...@comotivsystems.com>
Subject RE: 1.3 - A Line in the Sand
Date Wed, 04 Apr 2007 20:44:54 GMT
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
111 SW Columbia Street Ste. 950
Portland, OR  97201

Telephone:      503.224.7496
Cell:           503.997.1367
Fax:            503.222.0185



-----Original Message-----
From: Jess Holle [mailto:jessh@ptc.com]
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

View raw message