《slf4j官方文档》传统桥接API

原官网英文文档

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

请注意，对于您控制下的源代码，您确实应该使用slf4j-migrator。 本页描述的基于二进制的解决方案适用于您无法控制的软件。

从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将立即永久地解决与公共日志记录相关的类加载器问题。

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之后，而这个组件需要被嵌入到一个大型的应用环境中，而在这个应用环境中，JCL是一个标准的需要，这个时候slf4j-jcl.jar非常有用。您的软件组件仍然可以使用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文件，如下所述。

How does it work?它如何工作？

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替换log4j.jar。

请注意，您仍然需要SLF4J绑定及其依赖关系，log4j-over-slf4j才能正常工作。

在大多数情况下，替换jar文件就是从log4j迁移到SLF4J所需的全部内容。

请注意，由于此迁移，将不再获取log4j配置文件。 如果需要将log4j.properties文件迁移到logback，log4j转换器可能会有所帮助。 配置logback，请参考 它的手册 。

When does it not work?什么时候不起作用？

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

What about the overhead?系统开销

直接使用 log4j-over-slf4j 代替log4j的系统开销相对小很多。之前已经给出， log4j-over-slf4j 立即分配所有的工作给SLF4J, CPU的系统开销在几纳秒内应该忽略不计。有个内存系统开销，对应于每个日志器的hashmap的入口，这个对于有几千个日志器的大应用来说是可以接受的。另外，如果你选择logback作为底层日志系统，已知logback比log4j更快同时更节省内存，使用logback直接代替log4j的增益应该补偿了使用 log4j-over-slf4j 代替log4j的桥接花费。

og4j-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 bridge（jul到slf4j桥接）

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

注意性能 – 与其他桥接模块相反的名称为jcl-over-slf4j和log4j-over-slf4j，二者重实现了JCL和独立地log4j，jul-to-slf4j模块没有重实现java.util.logging，因为java.*下的包命名空间不能替换。反而，jul-to-slf4j等价地转换 LogRecord 对象到它们的SLF4J中。请注意转换工程导致的构建LogRecord实例的花费，而不是SLF4J日志器对于给定的等级是否已禁用了。因此，jul-to-slf4j转换可能严重地增加了禁用日志声明的系统开销（60倍或6000%），同时明显地影响开启日志声明的性能（大体上增加20%）。在LevelChangePropagator的帮助下，logback0.9.25版本可能完全消除禁用日志声明引起的60倍转换系统开销。

如果你关心应用的性能，只有当下列2种情况是真的时，是用SLF4JBridgeHandler是合适的：

1. 几乎没有u.l日志声明在运行
2. 已安装LevelChangePropagator

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

slf4j-jdk14.jar 是jul到SLF4J的绑定，将强制SLF4J的调用分配给jul。另一方面，jul-to-slf4j.jar，加上SLF4JBridgeHandler的安装，加上SLF4JBridgeHandler的安装,通过调用“SLF4JBridgeHandler.install()“将jul记录发送给SLF4J。因此，如果两个jar文件同时存在（SLF4JBridgeHandler已安装），slf4的调用将被分配给jul, jul记录将发送到SLF4J，导致一个死循环。