SLF4J官网

http://www.slf4j.org/legacy.html

翻译：

桥接旧版API

通常，您依赖的某些组件依赖于SLF4J以外的日志API。 您可能还假设这些组件在不久的将来不会切换到SLF4J。 为了处理这种情况，SLF4J附带了几个桥接模块，这些模块会将对log4j，JCL和java.util.logging API的调用重定向，就好像是对SLF4J API进行的操作一样。 下图说明了这个想法。

从Jakarta Commons Logging（JCL）迁移到SLF4J

jcl-over-slf4j.jar

为了简化从JCL到SLF4J的迁移，SLF4J发行版包括jar文件jcl-over-slf4j.jar。该jar文件旨在替代JCL 1.1.1版。它实现了JCL的公共API，但在下面使用了SLF4J，因此命名为“JCL over SLF4J”。
我们的 JCL over SLF4J 实现将允许您逐步迁移到SLF4J，尤其是在您的软件所依赖的某些库在可预见的将来继续使用JCL的情况下。您可以立即享受SLF4J的可靠性，并同时保持向后兼容性。 只需用jcl-over-slf4j.jar替换commons-logging.jar。随后，将由SLF4J而不是JCL完成底层日志记录框架的选择，并且没有令人头疼的JCL的类加载器麻烦。 底层日志记录框架可以是SLF4J支持的任何框架。 通常，用jcl-over-slf4j.jar替换commons-logging.jar将立即永久解决与Commons日志记录相关的类加载器问题。

slf4j-jcl.jar

切换到SLF4J API后，一些用户意识到在某些情况下必须使用JCL，因此他们对SLF4J的使用可能会成为问题。 对于这种不常见但很重要的情况，SLF4J提供了一个JCL绑定，可在文件slf4j-jcl.jar中找到。 JCL绑定会将通过SLF4J API进行的所有日志记录调用委托给JCL。 因此，如果由于某种原因现有的应用程序必须使用JCL，则该应用程序的该部分仍然可以以对大型应用程序环境透明的方式针对SLF4J API进行编码。 您选择的SLF4J API对于继续使用JCL的其余应用程序是不可见的。

jcl-over-slf4j.jar不应与slf4j-jcl.jar混淆

JCL-over-SLF4J，即jcl-over-slf4j.jar，在出于向后兼容性原因而需要支持JCL的情况下非常有用。 它可以用于解决与JCL相关的问题，而不必采用SLF4J API，该决定可以推迟到以后。
另一方面，在为组件采用SLF4J API之后，slf4j-jcl.jar很有用，该API需要嵌入在正式要求JCL的更大的应用程序环境中。 您的软件组件仍可以使用SLF4J API，而不会破坏大型应用程序。 实际上，slf4j-jcl.jar会将所有日志记录决策委派给JCL，以便您的组件对SLF4J API的依赖关系对于更大的整体而言是透明的。
请注意，不能同时部署jcl-over-slf4j.jar和slf4j-jcl.jar。 前一个jar文件将导致JCL将日志记录系统的选择委派给SLF4J，后一个jar文件将导致SLF4J将日志记录系统的选择委派给JCL，从而导致无限循环。

log4j-over-slf4j

SLF4J随附一个名为log4j-over-slf4j的模块。 它允许log4j用户将现有应用程序迁移到SLF4J，而无需更改任何代码，而只需用log4j-over-slf4j.jar替换log4j.jar文件，如下所述。

它是如何工作的？

log4j-over-slf4j模块包含最广泛使用的log4j类的替换，即org.apache.log4j.Category，org.apache.log4j.Logger，org.apache.log4j.Priority，org.apache.log4j.Level，org .apache.log4j.MDC和org.apache.log4j.BasicConfigurator。 这些替换类将所有工作重定向到其相应的SLF4J类。

要在您自己的应用程序中使用log4j-over-slf4j，第一步是先找到log4j-jar，然后将其替换为log4j-over-slf4j.jar。 请注意，您仍然需要SLF4J绑定及其依赖关系才能使log4j-over-slf4j正常工作。

在大多数情况下，只需要替换jar文件即可从log4j迁移到SLF4J。

请注意，作为此迁移的结果，将不再拾取log4j配置文件。 如果您需要将log4j.properties文件迁移到logback，则log4j转换器可能会有所帮助。 有关配置登录的信息，请参阅其手册。

什么时候不起作用？

当应用程序调用log4j-over-slf4j中不存在的log4j组件时，log4j-over-slf4j模块将无法工作。 例如，当应用程序代码直接引用log4j appenders，filters 或 PropertyConfigurator时，则log4j-over-slf4j不足以替代log4j。 但是，当通过配置文件配置log4j时，无论是log4j.properties还是log4j.xml，log4j-over-slf4j模块都应该可以正常工作。

那开销呢？

使用log4j-over-slf4j代替直接使用log4j的开销相对较小。 鉴于log4j-over-slf4j立即将所有工作委托给SLF4J，CPU开销应该可以忽略不计，约为几纳秒。 每个记录器都有一个与哈希映射中的条目相对应的内存开销，即使对于包含数千个记录器的超大型应用程序，这通常也应该是可以接受的。 此外，如果您选择logback作为基础日志系统，并且考虑到logback比log4j更快，内存效率更高，那么使用logback所获得的收益应该可以弥补使用log4j-over-slf4j而不是直接使用log4j带来的开销。

log4j-over-slf4j.jar和slf4j-log4j12.jar不能同时存在

slf4j-log4j12.jar的存在（即SLF4J的log4j绑定）将强制将所有SLF4J调用委派给log4j。 log4j-over-slf4j.jar的存在将把所有log4j API调用委派给它们的SLF4J等效项。 如果两者同时存在，则slf4j调用将委派给log4j，而log4j调用将重定向到SLF4j，从而导致无限循环。

jul-to-slf4j

jul-to-slf4j.jar包括一个java.util.logging（jul）处理程序，即SLF4JBridgeHandler，它将所有传入的jul记录路由到SLF4j API。 有关使用说明，请参见SLF4JBridgeHandler javadocs。

性能说明

与其他桥接模块（分别重新实现JCL和log4j的jcl-over-slf4j和log4j-over-slf4j）相反，jul-to-slf4j模块不会重新实现java.util.logging，因为 java.* 名称空间下的软件包无法更换。 相反，jul-to-slf4j会将LogRecord对象转换为它们的SLF4J等效项。 请注意，无论是否为给定级别禁用SLF4J记录器，此转换过程都会产生构造LogRecord实例的成本。 因此， 从SLF4J转换到SLF4J会严重增加禁用的日志语句的成本（60倍或6000％），并显着影响已启用的日志语句的性能（总体增加20％）。 从Logback版本0.9.25开始，可以借助LevelChangePropagator完全消除禁用日志语句的60倍转换开销。

如果您担心应用程序的性能，则仅当以下两个条件之一为真时，才适合使用SLF4JBridgeHandler：
few j.u.l. logging statements are in play
LevelChangePropagator has been installed

1. 很少j.u.l. 记录语句在起作用
2. 已安装LevelChangePropagator

jul-to-slf4j.jar和slf4j-jdk14.jar不能同时存在

slf4j-jdk14.jar的存在（即SLF4J的jul绑定）将强制将SLF4J调用委派给jul。 另一方面，通过调用 “SLF4JBridgeHandler.install()”，存在jul-to-slf4j.jar以及SLF4JBridgeHandler的安装会将jul记录路由到SLF4J。 因此，如果两个jar同时存在（并且已安装SLF4JBridgeHandler），则slf4j调用将委派给jul，而jul记录将路由到SLF4J，从而导致无限循环。

（完）