Logback natively implements the SLF4J API. This means that if you are using logback, you are actually using the SLF4J API. You could theoretically use the internals of the logback API directly for logging, but that is highly discouraged. All logback documentation and examples on loggers are written in terms of the SLF4J API.
So by using logback, you'd be actually using SLF4J and if for any reason you wanted to switch back to log4j, you could do so within minutes by simply dropping slf4j-log4j12.jar onto your class path.
When migrating from logback to log4j, logback specific parts, specifically those contained in logback.xml configuration file would still need to be migrated to its log4j equivalent, i.e. log4j.properties. When migrating in the other direction, log4j configuration, i.e. log4j.properties, would need to be converted to its logback equivalent. There is an on-line tool for that. The amount of work involved in migrating configuration files is much less than the work required to migrate logger calls disseminated throughout all your software's source code and its dependencies.
Why? Log4J has essentially been deprecated by Logback.
Is it urgent? Maybe not.
Is it painless? Probably, but it may depend on your logging statements.
Note that if you really want to take full advantage of LogBack (or SLF4J), then you really need to write proper logging statements. This will yield advantages like faster code because of the lazy evaluation, and less lines of code because you can avoid guards.
Finally, I highly recommend SLF4J. (Why recreate the wheel with your own facade?)
In the logging world there are Facades (like Apache Commons Logging, slf4j or even the Log4j 2.0 API) and implementations (Log4j 1 + 2, java.util.logging, TinyLog, Logback).
Basically you should replace your selfmade wrapper with slf4j IF and only IF you are not happy with it for some reason. While Apache Commons Logging is not really providing a modern API, slf4j and the new Log4j 2 facade is providing that. Given that quite a bunch of apps use slf4j as a wrapper it might make sense to use that.
slf4j gives a number of nice API sugar, like this example from slf4j docs:
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
It's variable substitution. This is also supported by Log4j 2.
However you need to be aware that slf4j is developed by QOS who also maintain logback. Log4j 2.0 is baked in the Apache Software Foundation. In the past three years a vibrant and active community has grown there again. If you appreciate Open Source as it is done by the Apache Software Foundation with all its guarantees you might reconsider using slf4j in favor to use Log4j 2 directly.
Please note:
In the past log4j 1 was not actively maintained while Logback was. But today things are different. Log4j 2 is actively maintained and releases on almost regular schedule. It also includes lot of modern features and -imho- makes a couple of things better than Logback. This is sometimes just a matter of taste and you should draw your own conclusions.
When reading you will see that Log4j 2 was inspired by Logback but also by other logging frameworks. But the code base is different; it shares almost nothing with Log4j 1 and zero with Logback. This lead to some improvements like in example Log4j 2 operates with bytestreams instead of Strings under the hood. Also it doesn't loose events while reconfiguring.
That all said the best idea is you choose the logging frameworks which just fits best to what you want to achieve. I would not switch a full framework if I would disable logging in production environment and just perform basic logging in my app. However if you do a bit more with logging just look at the features which are provided by the frameworks and their developers. While you get commercial support for Logback through QOS (i heard) there is currently no commercial support for Log4j 2. On the other hand if you need to do audit logging and need high performance provided by the async appenders it makes a lot of sense to check log4j 2.
Please note despite all comfort they provide, facades always eat a little performance. It's maybe not affecting you at all, but if you are on low resources you may need to save everything you can have.
Without knowing you requirements better it is almost impossible to give a recommendation. Just: don't switch just because a lot of people switch. Switch only because you see value of it. And the argumentation that log4j is dead doesn't count anymore. It's alive, and it's hot.
DISCLAIMER: I am currently VP, Apache Logging Services and involved in log4j as well.
Not exactly answering your question, but if you could move away from your self-made wrapper then there is Simple Logging Facade for Java (SLF4J) which Hibernate has now switched to (instead of commons logging).
SLF4J suffers from none of the class loader problems or memory leaks observed with Jakarta Commons Logging (JCL).
SLF4J supports JDK logging, log4j and logback. So then it should be fairly easy to switch from log4j to logback when the time is right.
Edit: Aplogies that I hadn't made myself clear. I was suggesting using SLF4J to isolate yourself from having to make a hard choice between log4j or logback.
Mature project or even project deep into development stages would probably loose more than gain from such upgrade, IMHO. Logback is certainly much more advanced in an array of points, but not to an extent for complete replacement in a working system. I would certainly consider logback for a new development, but existing log4j is good enough and mature for anything already released and met end user. This is very subjective, you should see cost yourself.
发布评论
评论（6）
Logback 原生实现了 SLF4J API。 这意味着如果您正在使用 logback，那么您实际上正在使用 SLF4J API。 理论上，您可以直接使用 logback API 的内部结构来进行日志记录，但强烈建议不要这样做。 所有 logback 文档和记录器示例都是根据 SLF4J API 编写的。
因此，通过使用 logback，您实际上正在使用 SLF4J，并且如果出于任何原因您想切换回 log4j，只需将 slf4j-log4j12.jar 拖放到类路径中即可在几分钟内完成。
从 logback 迁移到 log4j 时，logback 特定部分，特别是 logback.xml 配置文件中包含的部分，仍然需要迁移到其 log4j 等效项，即 log4j.properties。 当向另一个方向迁移时，log4j 配置（即 log4j.properties）需要转换为其 logback 等效项。 有一个在线工具。 迁移配置文件所涉及的工作量远比迁移分布在所有软件源代码及其依赖项中的记录器调用所需的工作量要少。
Logback natively implements the SLF4J API. This means that if you are using logback, you are actually using the SLF4J API. You could theoretically use the internals of the logback API directly for logging, but that is highly discouraged. All logback documentation and examples on loggers are written in terms of the SLF4J API.
So by using logback, you'd be actually using SLF4J and if for any reason you wanted to switch back to log4j, you could do so within minutes by simply dropping slf4j-log4j12.jar onto your class path.
When migrating from logback to log4j, logback specific parts, specifically those contained in logback.xml configuration file would still need to be migrated to its log4j equivalent, i.e. log4j.properties. When migrating in the other direction, log4j configuration, i.e. log4j.properties, would need to be converted to its logback equivalent. There is an on-line tool for that. The amount of work involved in migrating configuration files is much less than the work required to migrate logger calls disseminated throughout all your software's source code and its dependencies.
你应该？ 是。
为什么？ Log4J 基本上已被 登录。
紧急吗？ 也许不会。
是无痛的吗？ 可能，但这可能取决于您的日志记录。
请注意，如果您确实想充分利用 LogBack（或 SLF4J），那么您确实需要编写 正确的日志记录声明。 这将产生一些优点，例如由于惰性求值而导致代码更快，以及因为可以避免防护而减少代码行数。
最后，我强烈推荐SLF4J。 （为什么要用自己的外观重新创造轮子？）
Should you? Yes.
Why? Log4J has essentially been deprecated by Logback.
Is it urgent? Maybe not.
Is it painless? Probably, but it may depend on your logging statements.
Note that if you really want to take full advantage of LogBack (or SLF4J), then you really need to write proper logging statements. This will yield advantages like faster code because of the lazy evaluation, and less lines of code because you can avoid guards.
Finally, I highly recommend SLF4J. (Why recreate the wheel with your own facade?)
在日志记录世界中，存在外观（例如 Apache Commons Logging、slf4j 甚至 Log4j 2.0 API）和实现（Log4j 1 + 2、java.util.logging、TinyLog、Logback）。
基本上，如果并且仅当您由于某种原因对它不满意时，您应该用 slf4j 替换您自制的包装器。 虽然 Apache Commons Logging 并未真正提供现代 API，但 slf4j 和新的 Log4j 2 外观正在提供这一点。 鉴于相当多的应用程序使用 slf4j 作为包装器，使用它可能是有意义的。
slf4j 提供了许多不错的 API 糖，例如 slf4j 文档中的示例：
logger.debug("Temperature set to {}. Old temp was {}.", t, oldT);这是变量替换。 Log4j 2 也支持这一点。
但是您需要注意，slf4j 是由 QOS 开发的，QOS 也维护 logback。 Log4j 2.0 由 Apache Software Foundation 开发。 在过去的三年里，一个充满活力和活跃的社区再次发展起来。 如果您欣赏 Apache Software Foundation 提供的开源及其所有保证，您可能会重新考虑使用 slf4j，转而直接使用 Log4j 2。
请注意：
过去 log4j 1 并未得到积极维护，而 Logback 则在积极维护。 但今天情况不同了。 Log4j 2 得到积极维护并几乎定期发布。 它还包括许多现代功能，并且 - 恕我直言 - 在一些方面比 Logback 更好。 有时这只是一个品味问题，您应该得出自己的结论。
我写了一篇关于 Log4j 2.0 新功能的快速概述： http://www.grobmeier .de/the-new-log4j-2-0-05122012.html
阅读时您会发现 Log4j 2 受到 Logback 的启发，但也受到其他日志框架的启发。 但代码库不同； 它与 Log4j 1 几乎没有任何共享，与 Logback 共享为零。 这导致了一些改进，例如 Log4j 2 在底层使用字节流而不是字符串进行操作。 重新配置时也不会丢失事件。
Log4j 2 可以比我知道的其他框架更快地记录：http://www .grobmeier.de/log4j-2-performance-close-to-insane-20072013.html
用户社区似乎仍然比 Logbacks 大得多：http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html
综上所述，最好的想法是选择最适合您想要实现的目标的日志框架。 如果我在生产环境中禁用日志记录并仅在我的应用程序中执行基本日志记录，我不会切换完整的框架。 但是，如果您对日志记录进行更多操作，只需查看框架及其开发人员提供的功能即可。 虽然您通过 QOS 获得对 Logback 的商业支持（我听说），但目前还没有对 Log4j 2 的商业支持。另一方面，如果您需要进行审核日志记录并且需要异步附加程序提供的高性能，那么这样做很有意义检查 log4j 2.
请注意，尽管它们提供了所有的舒适感，但外墙总是会消耗一点性能。 它可能根本不会影响你，但如果你资源不足，你可能需要保存你能拥有的一切。
如果不更好地了解您的需求，几乎不可能给出建议。 只是：不要因为很多人更换而更换。 仅因为您看到它的价值而切换。 关于 log4j 已死的争论已经不再重要。 它还活着，而且很热。
免责声明：我目前担任 Apache 日志服务副总裁，并参与 log4j 工作。
In the logging world there are Facades (like Apache Commons Logging, slf4j or even the Log4j 2.0 API) and implementations (Log4j 1 + 2, java.util.logging, TinyLog, Logback).
Basically you should replace your selfmade wrapper with slf4j IF and only IF you are not happy with it for some reason. While Apache Commons Logging is not really providing a modern API, slf4j and the new Log4j 2 facade is providing that. Given that quite a bunch of apps use slf4j as a wrapper it might make sense to use that.
slf4j gives a number of nice API sugar, like this example from slf4j docs:
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);It's variable substitution. This is also supported by Log4j 2.
However you need to be aware that slf4j is developed by QOS who also maintain logback. Log4j 2.0 is baked in the Apache Software Foundation. In the past three years a vibrant and active community has grown there again. If you appreciate Open Source as it is done by the Apache Software Foundation with all its guarantees you might reconsider using slf4j in favor to use Log4j 2 directly.
Please note:
In the past log4j 1 was not actively maintained while Logback was. But today things are different. Log4j 2 is actively maintained and releases on almost regular schedule. It also includes lot of modern features and -imho- makes a couple of things better than Logback. This is sometimes just a matter of taste and you should draw your own conclusions.
I wrote a quick overview on the new Features of Log4j 2.0: http://www.grobmeier.de/the-new-log4j-2-0-05122012.html
When reading you will see that Log4j 2 was inspired by Logback but also by other logging frameworks. But the code base is different; it shares almost nothing with Log4j 1 and zero with Logback. This lead to some improvements like in example Log4j 2 operates with bytestreams instead of Strings under the hood. Also it doesn't loose events while reconfiguring.
Log4j 2 can log with higher speed than other frameworks I know: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html
And still the user community seems to be much bigger than Logbacks: http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html
That all said the best idea is you choose the logging frameworks which just fits best to what you want to achieve. I would not switch a full framework if I would disable logging in production environment and just perform basic logging in my app. However if you do a bit more with logging just look at the features which are provided by the frameworks and their developers. While you get commercial support for Logback through QOS (i heard) there is currently no commercial support for Log4j 2. On the other hand if you need to do audit logging and need high performance provided by the async appenders it makes a lot of sense to check log4j 2.
Please note despite all comfort they provide, facades always eat a little performance. It's maybe not affecting you at all, but if you are on low resources you may need to save everything you can have.
Without knowing you requirements better it is almost impossible to give a recommendation. Just: don't switch just because a lot of people switch. Switch only because you see value of it. And the argumentation that log4j is dead doesn't count anymore. It's alive, and it's hot.
DISCLAIMER: I am currently VP, Apache Logging Services and involved in log4j as well.
不完全回答你的问题，但如果你可以摆脱你自制的包装器，那么有 Simple Logging Facade for Java (SLF4J ) Hibernate 现在已切换到（而不是公共日志记录）。
SLF4J 支持 JDK 日志记录、log4j 和 logback。 因此，当时机成熟时，从 log4j 切换到 logback 应该相当容易。
编辑：抱歉我没有说清楚。 我建议使用 SLF4J 来让自己不必在 log4j 或 logback 之间做出艰难的选择。
Not exactly answering your question, but if you could move away from your self-made wrapper then there is Simple Logging Facade for Java (SLF4J) which Hibernate has now switched to (instead of commons logging).
SLF4J supports JDK logging, log4j and logback. So then it should be fairly easy to switch from log4j to logback when the time is right.
Edit: Aplogies that I hadn't made myself clear. I was suggesting using SLF4J to isolate yourself from having to make a hard choice between log4j or logback.
您的决定应该基于
您应该抵制仅仅因为 API“更新、更闪亮、更好”而更改 API 的冲动。 我遵循的原则是“如果它没有坏，就不要踢它”。
如果您的应用程序需要非常复杂的日志记录框架，您可能需要考虑原因。
Your decision should be based on
You should resist the urge to change APIs just because it's "newer, shinier, better." I follow a policy of "if it's not broken, don't kick it."
If your application requires a very sophisticated logging framework, you may want to consider why.
恕我直言，成熟的项目甚至深入开发阶段的项目可能会从这种升级中失去更多的收益。 Logback 在很多方面肯定要先进得多，但还没有达到完全替代工作系统的程度。 我当然会考虑将 logback 用于新的开发，但现有的 log4j 对于已经发布并满足最终用户的任何内容来说都足够好且成熟。 这是非常主观的，你应该自己看看成本。
Mature project or even project deep into development stages would probably loose more than gain from such upgrade, IMHO. Logback is certainly much more advanced in an array of points, but not to an extent for complete replacement in a working system. I would certainly consider logback for a new development, but existing log4j is good enough and mature for anything already released and met end user. This is very subjective, you should see cost yourself.