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:32:24 GMT
# 1 is relatively easy to achieve (it should be sufficient to add some constructors and accessors
to loggingevent in the 1.2 stream)
#2 is already there (sockethubreceiver, socketreceiver, logfilexmlreceiver, file/open xml
files in the UI)
#3 is already there - MDC entries show up as individual columns in the UI - NDC as a specific
column

mdc entries and NDC can be queried via the expression syntax - to filter on an MDC key, use:
PROP.somekey = somevalue 
in search, refine-focus filter and colorizing filters

See the tutorial for more info.

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

sdeboy@comotivsystems.com

www.comotivsystems.com



-----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



Mime
View raw message