简体   繁体   English

LoggerFactory.getLogger“root”与“class”名称的区别是什么?

[英]What the difference in LoggerFactory.getLogger “root” vs “class” name?

I'm trying to find the answer about the differences between: 我试图找到关于以下之间差异的答案:

class MyClass {
    private static Logger logger = LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME);
}

and: 和:

class MyClass {
    private static Logger logger = LoggerFactory.getLogger(MyClass.class);
}

Is it only useful with you are planning to do a fine logging setup? 它只对您计划进行精细的日志记录设置有用吗? Like separate the log of the class in a different file, print more/less informations for each one, etc. 就像在不同的文件中分离类的日志一样,为每个文件打印更多/更少的信息,等等。

I have this doubt because most of my classes I use LoggerFactory.getLogger(MyClass.class) but I think the LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME) is enough in the most of the cases. 我有这个疑问,因为我的大多数类都使用LoggerFactory.getLogger(MyClass.class)但我认为LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME)在大多数情况下都足够了。

Thanks! 谢谢!

Is it only useful with you are planning to do a fine logging setup? 它只对您计划进行精细的日志记录设置有用吗? Like separate the log of the class in a different file, print more/less informations for each one, etc. 就像在不同的文件中分离类的日志一样,为每个文件打印更多/更少的信息,等等。

This is correct. 这是对的。 By controlling your logging down to the class level, by giving each class their own logger, you can more finely control the logging. 通过将日志记录控制到类级别,通过为每个类提供自己的记录器,您可以更精细地控制日志记录。 For example, we typically log all log entries (regardless of level) for classes in our packages, eg my.employer.com.team.project . 例如,我们通常会记录包中类的所有日志条目(无论级别如何),例如my.employer.com.team.project We then log ERROR for all other loggers. 然后我们记录所有其他记录器的ERROR。 We then have the ability to view all the loggers that are being used on the application and can remotely enable/disable any logger we want in real-time. 然后,我们可以查看应用程序上正在使用的所有记录器,并可以实时远程启用/禁用我们想要的任何记录器。

I have this doubt because most of my classes I use LoggerFactory.getLogger(MyClass.class) but I think the LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME) is enough in the most of the cases. 我有这个疑问,因为我的大多数类都使用LoggerFactory.getLogger(MyClass.class),但我认为LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME)在大多数情况下都足够了。

If you give all your classes the same logger, then they will all behave in the same way. 如果您为所有类提供相同的记录器,那么它们将以相同的方式运行。 I think you are right that for most cases you will treat all your classes' logging the same way, but that is not always the case. 我认为你是对的,在大多数情况下,你会以同样的方式对待你所有类的日志,但情况并非总是如此。 Also, if you are writing library code, then you must not use the root logger because now you remove the ability of the user's of your library to tune your libraries' logs. 此外,如果您正在编写库代码,那么您不能使用根记录器,因为现在您删除了库的用户调整库日志的功能。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 LoggerFactory.getLogger(ClassName.class) vs LoggerFactory.getLogger(this.getClass().getName()) - LoggerFactory.getLogger(ClassName.class) vs LoggerFactory.getLogger(this.getClass().getName()) Slf4j LoggerFactory.getLogger和声纳 - Slf4j LoggerFactory.getLogger and sonarqube SessionBean 上的实例 LoggerFactory.getLogger 上的 StackOverFlowError - StackOverFlowError on instance LoggerFactory.getLogger on a SessionBean SLF4J,避免每次都写 LoggerFactory.getLogger(MyClassName.class) - SLF4J, To avoid writing LoggerFactory.getLogger(MyClassName.class) every time 自定义Logger消息格式Java LoggerFactory.getLogger(getClass()) - Custom Logger message format Java LoggerFactory.getLogger(getClass()) 为什么不建议每次都调用LoggerFactory.getLogger(...)? - Why calling LoggerFactory.getLogger(…) every time is not recommended? LoggerFactory不能getLogger - LoggerFactory cannot getLogger java:找不到符号符号:类getLogger位置:类org.slf4j.LoggerFactory - java: cannot find symbol symbol: class getLogger location: class org.slf4j.LoggerFactory Logger.getLogger(class_name.class.getName())导致NullPointerException - Logger.getLogger(class_name.class.getName()) leads to NullPointerException 传递 MethodHandles.lookup().lookupClass() 与传递 Class<!--?--> getLogger 方法 - Passing MethodHandles.lookup().lookupClass() vs passing Class<?> to getLogger method
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM