BFergerson commented on issue #4545: URL: https://github.com/apache/skywalking/issues/4545#issuecomment-730095874
> > Why does `LogbakLoggerFactoryInstrumentation` need to know about `org.slf4j.LoggerFactory`? > > > > * I would assume slf4j wouldn't come into the picture as under the hood it is using other logging frameworks. As long as those logging frameworks are supported I don't see why there would need to be any code related to slf4j. > > 1. Through the LogContext instance, We can obtain some information that cannot be directly obtained by intercepting the `logger.trace()` method, such as the package name, the stack trace of the exception associated with the logging event. > > 2. And if we want to use PatternLayoutEncoder to fully support the formatting function, the LogContext instance is also necessary. Of course, if we can obtain the necessary information through other methods, we can implement the formatting function ourselves > If you have a better idea to obtain the necessary information, please put it forward and we will verify it together. Thank you! I'm still not seeing why there is a need for knowledge about slf4j. What if someone uses Logback without using slf4j? I would think that means this plugin would no longer work. Also, I've confirmed that the exact instance which is being stored in `LOCAL_LOGGER_CONTEXT` is what is available in `EnhancedInstance` on `LogbackLoggerInterceptor`. This evaulates to true: ``` LoggerContextUtil.LOCAL_LOGGER_CONTEXT.get() == ((Logger)((Object) objInst)).getLoggerContext() ``` Given you change `LogbackLoggerFactoryInstrumentation.ENHANCE_CLASS` to `ch.qos.logback.classic.LoggerContext`. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
