> 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. Sure we have several framework support classes that setup loggers, which can not be done in a static context, so they have to: Logger log = LoggerFactory.getLogger(getClass()); This is not something that can be easily changed without completely breaking everything using those classes. 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 $. Its not the stack traces, is the log messages which include the logger name which is problematic, as well as the configuration of loggers when/if levels have to be changed. And our product is an application server, so the logs are an aspect of the system which users do consume. > 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. I’m not interested in debating semantics here. I’m trying to ask if folks think it may be a good (or bad) idea for slf4j-api to cope with enhanced classes to simplify/normalize logger names for both output handling (ie what shows up in the appender outputs) as well as for configuration (ie. wheter you configure the class-name or class-name$$EnhancerByGuice$$. I can and likely will adapt our software to use the helper I mentioned to keep things simple/normalized, but I am curious to see if anyone things this should be generalized into the slf4j-api generally or not. > 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). I am not aware of any pluggable aspect of slf4j-api here to do that. I was considering an optional system property which when true would kick in in org.slf4j.LoggerFactory.getLogger(Class) to handle this behavior and then delegate to another static helper which the application could provide to sanitize the class reference before handing it over to the underlying provider. —jason
_______________________________________________ slf4j-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-user
