用 Java 登录是怎么回事?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/354837/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What's Up with Logging in Java?
提问by Loki
Why one would use one of the following packages instead of the other?
为什么会使用以下软件包之一而不是另一个?
- Java Logging
- Commons Logging
- Log4j
- SLF4j
- Logback
- Java日志
- 公共日志记录
- 日志4j
- SLF4j
- 登录
采纳答案by Stephen
In chronological order of api apperance (as far as I know):
按照api外观的时间顺序(据我所知):
- Log4j because most everybody uses it (in my experience)
- Commons Logging because open source projects use it (so they can integrate with whatever logging framework is used in the integrated solution); especially valid if you're an API/Framework/OSS and you rely on other packages that use Commons Logging.
- Commons Logging because you don't want to "lock down" to a particular logging framework (so instead you lock down to what Commons Logging gives you instead) - I don't think it is sensible to decide using this point as the reason.
- Java logging because you don't want to add in an extra jar.
- SLF4j because it's newer than Commons Logging and provides parameterized logging:
- Log4j 因为大多数人都使用它(以我的经验)
- Commons Logging 因为开源项目使用它(因此它们可以与集成解决方案中使用的任何日志框架集成);如果您是 API/Framework/OSS 并且依赖其他使用 Commons Logging 的包,则尤其有效。
- Commons Logging 因为你不想“锁定”到一个特定的日志框架(所以你锁定了 Commons Logging 给你的东西) - 我认为决定使用这一点作为原因是不明智的。
- Java 日志记录,因为您不想添加额外的 jar。
- SLF4j 因为它比 Commons Logging 更新并提供参数化日志记录:
logger.debug("The entry is {}.", entry);
//which expands effectively to
if (logger.isDebugEnabled()){
// Note that it's actually *more* efficient than this - see Huxi's comment below...
logger.debug("The entry is " + entry + ".");
}
- Logback because it's newer than log4j and again, supports parameterized logging, as it implements SLF4j directly
- SLF4j/Logback because it's written by the same guy who did log4j, so he's made it better (according to Ken G- thanks. It seems to fit when looking at their earlier news posts)
- SLF4j because they also publish a log4j adapter so you don't have to "switch out" log4j in older code - just make log4j.properties use SLF4j and it's configuration
回答by Julien Chastang
I find logging in Java to be confusing, inconsistent, poorly documented, and especially haphazard. Moreover, there is a huge amount of similarity between these logging frameworks resulting in duplication of effort, and confusion as to what logging environment you are actually in. In particular, if you are working in a serious Java web application stack, you are often in multiplelogging environments at one time; (e.g hibernate may use log4j, and tomcat java.util.logging). Apache commons is meant to bridge different logging frameworks, but really just adds more complexity. If you do not know this ahead of time, it is utterly bewildering. Why are my log messages not printing out to the console, etc.? Ohh because I am looking at the Tomcat logs, and not log4j. Adding yet another layer of complexity, the application server may have global logging configurations that may not recognize local configurations for a particular web application. Lastly, all these logging frameworks are WAY TOO COMPLICATED. Logging in Java has been a disorganized mess leaving developers like me frustrated and confused.
我发现登录 Java 令人困惑、不一致、文档不足,而且特别随意。此外,这些日志框架之间存在巨大的相似性,导致工作重复,以及您实际所处的日志环境的混乱。特别是,如果您在一个严肃的 Java Web 应用程序堆栈中工作,您经常处于多一次记录环境;(例如,hibernate 可能使用 log4j 和 tomcat java.util.logging)。Apache commons 旨在桥接不同的日志框架,但实际上只是增加了更多的复杂性。如果你事先不知道这一点,那将是完全令人困惑的。为什么我的日志消息没有打印到控制台等?哦,因为我正在查看 Tomcat 日志,而不是 log4j。又增加了另一层复杂性,应用程序服务器可能具有全局日志配置,这些配置可能无法识别特定 Web 应用程序的本地配置。最后,所有这些日志框架都太复杂了。登录 Java 一直是一团乱麻,让像我这样的开发人员感到沮丧和困惑。
Early versions of Java did not have a built-in logging framework leading to this scenario.
早期版本的 Java 没有导致这种情况的内置日志记录框架。
回答by Huxi
There's one important point that wasn't mentioned before:
有一个重要的点之前没有提到:
SLF4J (and both Logback and LOG4J as the logging backend) have support for a so called Mapped Diagnostic Context (MDC, see javadocand documentation).
SLF4J(以及作为日志后端的 Logback 和 LOG4J)支持所谓的映射诊断上下文(MDC,请参阅javadoc和文档)。
This is essentially a thread-local Map<String,String> which you can use to add additional context information to your logging event. The current state of the MDC is attached to every event.
这本质上是一个线程本地 Map<String,String>,您可以使用它向日志事件添加额外的上下文信息。MDC 的当前状态附加到每个事件。
This can be incredibly useful if you put stuff like the username and the URL of the request (in case of a webapp) into it. This can be done automatically using a filter, for example.
如果您将用户名和请求的 URL(在 web 应用程序的情况下)等内容放入其中,这将非常有用。例如,这可以使用过滤器自动完成。
回答by Ken Gentle
See also answers to the question What are the best practices to log an error?, especially:
另请参阅问题记录错误的最佳做法是什么?, 尤其:
There are some potential classloading issues with Commons Logging.
Log4J and SLF4J were developed by the same person, learning from issues found in practice with Log4J.
Commons Logging 存在一些潜在的类加载问题。
Log4J 和 SLF4J 由同一个人开发,从 Log4J 实践中发现的问题中学习。
回答by kdgregory
The Commons Logging overviewgives the reason for its existence: logging from library code, when you have no control over the underlying logging framework. Very important for the various Apache projects, which will be linked into outside applications. Perhaps not so important for internal IT projects, where you have complete control.
该共享日志记录概述给出了其存在的理由:从库中的代码记录,当你拥有了潜在的日志框架没有控制权。对于将链接到外部应用程序的各种 Apache 项目非常重要。对于您拥有完全控制权的内部 IT 项目而言,这可能不是那么重要。
That said, I write to Commons Logging, as do many of the other developers I know. The reason is to minimize mental baggage: you can change projects or jobs, and not have to learn a new framework (provided the new job/project also uses CL, and/or you can convince them to move to it).
也就是说,我写信给 Commons Logging,我认识的许多其他开发人员也是如此。原因是尽量减少心理负担:您可以更改项目或工作,而不必学习新框架(前提是新工作/项目也使用 CL,和/或您可以说服他们转向它)。
Also, there is some value to creating your own wrappers around whatever framework you use. As described here, I like to use a LogWrapper object to provide custom stringification (important), and minimize the visual clutter of logging statements (less important).
此外,围绕您使用的任何框架创建自己的包装器也有一定的价值。如上所述这里,我喜欢用LogWrapper目的是提供自定义的字串(重要),并最大限度地减少日志报表(不那么重要)的视觉混乱。
回答by Markus Lausberg
In our company project we use LOG4j and it is very easy to use like Stephen showed in his example. We also have written our own pattern classes for LOG4j so you can create your own output file schemas. You can describe how your log file should look like. It is possible to enhance the original log4j classes.
在我们公司的项目中,我们使用 LOG4j,它非常易于使用,就像 Stephen 在他的示例中展示的那样。我们还为 LOG4j 编写了我们自己的模式类,因此您可以创建自己的输出文件模式。您可以描述日志文件的外观。可以增强原始 log4j 类。
All LOG4j properties you can change in a log4j.properties file, so you can use different files for different projects.
您可以在 log4j.properties 文件中更改所有 LOG4j 属性,因此您可以为不同的项目使用不同的文件。
Java logging is not my favorit, but this could be because i use log4j from the beginning.
Java 日志记录不是我的最爱,但这可能是因为我从一开始就使用 log4j。
回答by Michael Rutherfurd
Generally I would default to using Log4J.
通常我会默认使用 Log4J。
I would use Java Logging if I didn't mind a dependency on Java 1.4 but I would still use Log4J in preference.
如果我不介意依赖 Java 1.4,我会使用 Java Logging,但我仍然会优先使用 Log4J。
I would use Commons Logging if I was enhancing something that already used it.
如果我要增强已经使用过的东西,我会使用 Commons Logging。
回答by tsimon
I would suggest creating a thin logging facade that can write to any of the logging frameworks, at which point the choice of backing engine become pretty much a moot point.
我建议创建一个可以写入任何日志框架的薄日志外观,在这一点上,支持引擎的选择几乎成为一个有争议的问题。

