[slf4j-user] Can/should slf4j handle Guice AOP class names?
Joachim Durchholz
jo at durchholz.org
Tue Oct 29 09:25:01 CET 2013
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).
More information about the slf4j-user
mailing list