Am 29.10.2013 01:32, schrieb planet57:
I’m wondering if perhaps slf4j could/should handle unwrapping Guice
AOP _enhanced_ classes when creating Logger instances?
Some code simply can not use static class references and has to use
obj.getClass() to configure a Logger instance.
Can you elaborate what use case that would be?
I haven't seen that yet.
This can however result in ugly Guice turds in the logger name if
the class was enhanced, for example:
com.whatever.EventPublisherImpl$$EnhancerByGuice$$
… instead of what is generally preferable:
com.whatever.EventPublisherImpl
Is this a serious problem?
End users aren't supposed to see the stack traces, and support people
shouldn't care that much, they'll quickly learn to ignore anything after
a $.
The AOP stuff here is an impl detail and IMO should leak out into
> logging context.
A log can contain stack traces, that's even more implementation details.
Actually, the class and thread name in each log line are implementation
details, too.
That said, I can see some use cases where you'd want an appender, say,
for overall administration, emitting just the messages that tell him
when a job started, when it ended, major steps, and possibly whether it
failed.
You'd want an appender that wrote to the administrator log, and set a
flag in the MDC whether the message is for the administrator or not
(plus a way in the application to set that flag).
On the other hand, such monitoring sounds like a dedicated use case of
the application, so maybe trying to handle that via SLF4J is not quite
the right approach. (E.g. some library may emit messages that just
happen to fit the administrator appender, and then the administrator
will get spurious messages.)
I’m wondering if there is a simple/elegant way to handle this in the
> slf4j-api (and become generally transparent to applications)
Possibly a pattern evaluator for emitting class names that strips the
enhancement markers. Or replaces them with something shorter - sometimes
people might want to know whether an enhanced or an unenhanced class was
called (the unenhanced version of any class can stick around and
actually get called e.g. in Spring, I think).
_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
