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
_______________________________________________
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
