logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: A new thread for log4j 2.0 discussion (Was Re: svn commit: r943816 [1/9] - in /logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers: ./ log4j12-api/ log4j12-api/src/ log4j12-api/src/main/ log4j12-api/src/main/java/ log4j12-api/src/main/java/org/ log4j12-api/src/main/java/org/apache/ log4j12-api/sr...)
Date Sat, 22 May 2010 07:01:10 GMT

On May 21, 2010, at 11:15 PM, Ralph Goers wrote:
>>> 1. I first created an API that had the features I was looking for. That is in
log4j2-api. While it supports logging a String or an Object it really uses a Message interface
which is valuable as it allows users to log self-describing objects in a convenient manner.
>> My thinking was the message interface would end up so minimal that might as well
just use Object.
> I don't think so. For example, take a look at StructuredDataMessage and LocalizedMessage.
Those allow you to do some interesting things. The idea is that it is easy for users to extend
without having to muck with the internals. Ceki handled this by creating logback-classis,
logback-access and logback-audit. That seemed to me to be a very heavyweight approach to accomplish

Definitely will look at, just wanted to let you know my unchallenged inclination.  I'm willing
to be convinced.

A little off track, there was a long ago thread that wandered between log4j and commons logging
about localization of logging that came to mind.  Took me a while to find it, but the threads
of interest are:


>>> 2. I don't like the way Logback binds to the implementation. I used a technique
I had used in a previous logging framework and used a file to define the implementation class.
In theory, the API could be modified to support multiple logging implementation simultaneously,
although I have no plans to implement that.
>> Not something that I've thought about.
> Probably not. It just occurred to me that it is possible as I was implementing it but
decided it wasn't an itch I needed to scratch at the moment.
>>> 3. Logback suffers from a serious architectural problem that is rooted in Log4j.
The configured loggers are mixed with the loggers returned from the Logger factory. This makes
it impossible to reconfigure atomically. With Logback the reset method is called on the context
which essentially causes the system to be in an undefined state until the new configuration
is completed (log records that should be logged are lost). To solve this I used a design that
I again borrowed from my previous framework. The configuration is separated and on a reconfiguration
the new configuration will be created and then all the loggers will be updated to use it.
While there will be a period where some loggers are using the old configuration and some the
new there is never a point where loggers aren't configured at all.
>> I think that is along the line that I was thinking, basically there is an immutable
configuration state object that is swapped out as an atomic operation with notification to
allocated loggers.
> Exactly.
>>> 4. Similar to Logback I added support for Markers and global filters. In addition,
filters on Loggers are also supported. Unlike Logback, there is only a single Filter interface
used for global filters, logger filters and appender filters.
>> I've never had a clear description of the use cases behind Markers.  As far as I
can gather, it is a specialized case of a user supplied context.  At the core, I think it
would fit into a general user-supplied context object.  MDC and NDC would be part of the thread-supplied
context and there'd be a global context and a call-site context.  In the core, I'd expect
the context parameters to just be Object and let the layout level cast to specific known interfaces
as needed.  During the synchronous extraction phase, an immutable package would be assembled
for from log request parameters and the contexts based on the needs of the layout's formatting
> I think I'd need to see code to get what you are driving at.  In the code I checked in
it does have the MDC & NDC and does have a global context, although I haven't added variables
to it yet. It also has the configuration which can also have variables, but probably for a
different purpose. I don't know what you mean by "call-site context".  

I was meaning the context that is only valid for the duration of the call, essentially the
info that you'd get from new Throwable().getStackTrace().

> The value of Markers is that they are fast and easy to filter on. I use them for Entry
and Exit so that you can easily filter them out (admittedly this can also be done via the
TRACE level) as well as catching and throwing. In addition, I also use a Marker to identify
audit events. Anything with that Marker will always be logged.

Still seems like a specialized user context object to me.  Don't know if there is a user-supplied
context object outside of it.  Will need to take a look.
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message