[slf4j-dev] [logback-dev] RFC: LoggingEvent redesign

[Ralph Goers]

On Feb 24, 2009, at 3:32 PM, Joern Huxhorn wrote:

> Hi Ceki
>
> On 24.02.2009, at 20:00, Ceki Gulcu wrote:
>
>>
>> Joern,
>>
>> Accepting parameters of type Object instead of String opens the  
>> door for nasty bugs as you point out. At the same time, it also  
>> constitutes an important extension point for logback within the  
>> limits imposed by the SLF4J API.
>>
>
> At this point I'm wondering if such an extension is really a good  
> idea at all.
>
> Don't use a hammer to screw a screw. Ok, it would kind of work, but  
> you'd be better of using a screwdriver instead.
>
> The hammer is slf4j/logback, a magnificent framework for application  
> logging. The screwdriver would be an auditing framework (see http://audit.qos.ch/apidocs/index.html 
>  :D).
> A pretty good indicator that slf4j is, in fact, the wrong tool for  
> the job, is that log levels are mostly meaningless in an audit  
> context.

This discussion is now getting very much off topic and probably should  
move to slf4j dev. So I've addressed it to both lists. Feel free to  
drop logback dev.

While it is true that levels are meaningless, using the same API,  
configuration, Appenders, etc has considerable value.  The differences  
I have between "normal" logging and "audit" logging are:
1. Events should always be logged. Filtering should only be used to  
determine what Appender to use.
2. The log record typically consists of several data elements, not  
just a text message.
3. Only a single Logger is required specifically for the use of event  
logging.

No offense to Ceki, but I believe audit.qos.ch is taking a slightly  
different approach than what I am doing. I've been doing this quite a  
while in my own proprietary code and see no need to keep it that way,  
especially since it is so simple. We simply leverage the MDC for all  
our request context information (i.e. these appear in every audit  
event that might occur on a request) and use the EventData to add  
information about the specific event. That's it.  Where the value-add  
is is in creating Appenders that can provide guaranteed delivery since  
that is a requirement of most applications and that is where stuff can  
get really complicated.

Ralph