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