问题三： 在生产环境中编译并部署应用程序后，您是否预计确实需要能够更改应用程序中的复杂日志记录配置？ 您的配置听起来是否类似于“来自此类的严重消息通过电子邮件发送给支持人员；来自类子集的严重消息被记录到我们服务器上的系统日志守护进程；来自类的另一个子集的警告消息被记录”到网络驱动器 A 上的文件，然后来自各处的所有消息都记录到网络驱动器 B 上的文件中”？ 您是否认为自己每隔几天就会调整一次？
Question One : Do you anticipate a need for any of the clever handlers that Log4j has that JUL does not have, such as the SMTPHandler, NTEventLogHandler, or any of the very convenient FileHandlers?
Question Two : Do you see yourself wanting to frequently switch the format of your logging output? Will you need an easy, flexible way to do so? In other words, do you need Log4j's PatternLayout?
Question Three : Do you anticipate a definite need for the ability to change complex logging configurations in your applications, after they are compiled and deployed in a production environment? Does your configuration sound something like, "Severe messages from this class get sent via e-mail to the support guy; severe messages from a subset of classes get logged to a syslog deamon on our server; warning messages from another subset of classes get logged to a file on network drive A; and then all messages from everywhere get logged to a file on network drive B"? And do you see yourself tweaking it every couple of days?
If you can answer yes to any of the above questions, go with Log4j. If you answer a definite no to all of them, JUL will be more than adequate and it's conveniently already included in the SDK.
That said, pretty much every project these days seems to wind up including log4j, if only because some other library uses it.
log4j is a much nicer package overall, and doesn't have some of the hiccups that java.util.logging contains. I'd second that using log4j directly is easier than using the commons logging.
I recommend using Apache Commmons Logging as your logging interface. That way you have the flexibility to switch logging implementations anytime you want without requiring any code changes on your end.
I recommend that you use the Simple Logging Facade for Java (SLF4J). It supports different providers that include Log4J and can be used as a replacement for Apache Commons Logging.
Log4j has been around for a long time, and it works very well. I have no scientific study to back it, but based on what I've seen at a large number of clients, it is easily the logging framework that I see used more than any other. It has been around for a long time, and not been replaced by the Next Big Logging Framework, which says something.
It is dead simple to set up, and easy to learn the basic appenders (outputs). There are a whole host appenders that are available, including:
ConsoleAppender
DailyRollingFileAppender
ExternallyRolledFileAppender
FileAppender
JDBCAppender
JMSAppender
NTEventLogAppender
RollingFileAppender
SMTPAppender
SocketAppender
SyslogAppender
TelnetAppender
WriterAppender
Plus others. It isn't difficult to write your own appender either. Additionally there is a great deal of flexibility in each of the appenders that allow you to control specifically what is output in your log.
One note, I had a series of classloader problems when I used apache commons logging in addition to log4j. It was only for one specific application, but I found it simpler to use log4j alone, rather than to have the flexibility offered when using an abstraction layer like commons logging.
发布评论
评论（7）
我想说，您可能对 util.logging 满足您所描述的需求感到满意。
对于一个好的决策树，请查看 Log4j 与 java.util.logging
也就是说，现在几乎每个项目似乎都包含了 log4j，哪怕只是因为其他一些库使用了它。
I'd say you're probably fine with util.logging for the needs you describe.
For a good decision tree, have a look at Log4j vs java.util.logging
That said, pretty much every project these days seems to wind up including log4j, if only because some other library uses it.
java.util.logging 提供了一个全面的日志记录包，没有其他一些提供的多余包袱。
java.util.logging offers a comprehensive logging package without the excess baggage some of the others provide..
总体而言，log4j 是一个更好的包，并且没有 java.util.logging 包含的一些问题。 我想说的是，直接使用 log4j 比使用公共日志记录更容易。
log4j is a much nicer package overall, and doesn't have some of the hiccups that java.util.logging contains. I'd second that using log4j directly is easier than using the commons logging.
我建议使用 Apache Commmons Logging 作为日志记录界面。 这样您就可以随时灵活地切换日志记录实现，而无需更改任何代码。
I recommend using Apache Commmons Logging as your logging interface. That way you have the flexibility to switch logging implementations anytime you want without requiring any code changes on your end.
我会选择 log4j。 log4j 的可能性根本没有过时！
I would go with log4j. The possibilites with log4j is not obsolete at all!
我建议您使用Simple Logging Facade for Java (SLF4J)。 它支持包括 Log4J 在内的不同提供程序，并且可以用作 Apache Commons Logging 的替代品。
I recommend that you use the Simple Logging Facade for Java (SLF4J). It supports different providers that include Log4J and can be used as a replacement for Apache Commons Logging.
Log4j 已经存在很长时间了，并且运行得非常好。 我没有科学研究支持它，但根据我在大量客户中看到的情况，它很容易成为我认为使用最多的日志框架。 它已经存在很长时间了，并且没有被下一个大型日志框架取代，这说明了一些事情。
它的设置非常简单，并且很容易学习基本的附加程序（输出）。 有可用的整个主机附加程序，包括：
加上其他。 编写自己的appender 也不难。 此外，每个附加程序都具有很大的灵活性，允许您专门控制日志中的输出内容。
需要注意的是，当我除了 log4j 之外还使用 apache commons 日志记录时，遇到了一系列类加载器问题。 它仅适用于一个特定的应用程序，但我发现单独使用 log4j 比使用公共日志记录等抽象层时提供的灵活性更简单。
请参阅这篇文章
更多详细信息：
祝你好运！
Log4j has been around for a long time, and it works very well. I have no scientific study to back it, but based on what I've seen at a large number of clients, it is easily the logging framework that I see used more than any other. It has been around for a long time, and not been replaced by the Next Big Logging Framework, which says something.
It is dead simple to set up, and easy to learn the basic appenders (outputs). There are a whole host appenders that are available, including:
Plus others. It isn't difficult to write your own appender either. Additionally there is a great deal of flexibility in each of the appenders that allow you to control specifically what is output in your log.
One note, I had a series of classloader problems when I used apache commons logging in addition to log4j. It was only for one specific application, but I found it simpler to use log4j alone, rather than to have the flexibility offered when using an abstraction layer like commons logging.
See this article for
more details:
Good luck!