[logback-dev] RFC: LoggingEvent redesign
rgoers at apache.org
Wed Feb 25 16:08:12 CET 2009
On Feb 25, 2009, at 6:11 AM, Joern Huxhorn wrote:
> I wasn't trying to say that Ralph is doing anything wrong and I
> sincerely hope that he does not have that impression. I have no idea
> about audit logging at all so both Ralph and you will probably know
> well what you are doing.
> He is using undocumented behavior, though, if I'm not entirely
First, I prefer to call it "Event Logging" even though it is more or
less the same thing. It really doesn't use undocumented behavior. It
serializes the data into an XML string and passes that in the message.
If the arguments are not available then the "message" is deserialized.
But if they are there it takes advantage of that for better
performance. Feel free to take a look at the actual code. I committed
it to slf4j-ext last night - although it needs cleaning up as some of
the style conventions are wrong.
I don't take offense at technical discussions on mailing lists. A lot
can get misinterpreted. Instead, I suggest you take a look at the code
and see if you think it is a horrible idea. What I'm currently
actually using, but would replace with this, does have more knowledge
of Logback, specifically so it can pass the objects to the Appender.
Unfortunately (at least I think so), SLF4J's LocationAwareLogger
doesn't provide a method to pass that information along.
>> In abstract terms, allowing Object-typed argument arrays is intended
>> as a last ditch extension point.
>> There are many data points contained in a logging event. There are
>> fairly fixed and structured points such as the time, logger, level
>> the exception. There are less structured data points such as the MDC,
>> and logger context properties. The logging event message is a special
>> case, in the sense that it can hold any string value and assuming a
>> object-to-string encoding mechanism, it can be used to transport
>> objects. (Logback does not provide any such encodings nor does it
>> explicitly support such a transport mechanism.) The only remaining
>> unstructured data point is the argument array, typed as Object.
> I disagree. I just implemented an enhanced version of the log4j NDC
> myself as you suggested on the SLF4J mailinglist. It's implemented
> similar to the logback MDC but isn't serialized/used by any standard
> appender. My multiplex-appenders, on the other hand, *are* evaluating
> it, thus adding an additional data point to the LoggingEvent.
> Wouldn't a similar extension be possible in Ralphs case?
I assume an NDC is based on a ThreadLocal? This works well for data
that lasts the lifetime of the request in progress. It is dangerous to
use for data for a specific event as that data must be cleared after
the event is completed - without disturbing other data that might have
been stored in it.
More information about the logback-dev