[slf4j-dev] EventLogging (was Re: [logback-dev] RFC: LoggingEvent redesign)

[Ralph Goers]

I figured the easiest way to discuss this was over code so I checked  
in the EventLogger classes. If it is OK I'll add documentation for it.  
Otherwise the classes can easily be reverted.

Ralph

On Feb 24, 2009, at 5:20 PM, Ralph Goers wrote:

>
> 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
>