[logback-dev] RFC: LoggingEvent redesign

[Ralph Goers]

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  
> very
> well what you are doing.
> He is using undocumented behavior, though, if I'm not entirely  
> mistaken.

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  
>> and
>> 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  
> quite
> 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.

Ralph