我使用SLF4J 作为日志外观，让用户决定在哪里以及记录什么。现在万一发生崩溃，我想向服务器发送一个包含调试信息的文件——这基本上意味着一个日志文件。既然我们已经将所有日志语句分散在代码中，为什么不使用它们呢？
所以基本上，我想通过 SLF4J 以编程方式创建一个日志文件，对仍然可以插入自己的日志后端和配置的用户透明。
我的第一个想法是实现org.slf4j.impl.StaticLoggerBinder，提供我自己的记录器实现，该记录器进行记录，然后委托给用户配置的记录器。但是，我看到了一些问题：如果用户放置了一个正常的日志记录后端，那么org.slf4j.impl.StaticLoggerBinder 的多个实例在类路径上。这将发出警告，我可能无法确定我的实现是被调用的。
有没有更好的解决方案？完全不同的方法？这个想法本质上是坏的吗？如何做到这一点？
【问题讨论】：
标签： java logging remote-debugging slf4j
SLF4J 的重点不是让应用程序的最终用户选择他们的日志框架（他们为什么要关心？），而是让开发人员包含一个库，而不受库选择的日志框架的束缚。
因此，如果您想从已部署的应用程序上传调试信息，则可以修复日志记录实现。如果需要，用户仍然可以编辑实现的配置文件。
【讨论】：
由于 SLF4J 是开源的，您可以修改它以使用除org.slf4j.impl.StaticLoggerBinder 之外的其他类。然后您的自定义StaticLoggerBinder 类可以加载原始的、用户提供的org.slf4j.impl.StaticLoggerBinder（如果存在）。
另一个想法是在您的应用程序中使用自定义LoggerFactory（不是org.slf4j.LoggerFactory），它返回一个Logger 委托。这个委托类委托日志记录方法调用原始的Logger 实现，并在必要时将日志发送到服务器。
无论如何，在我看来，两者都是一种尴尬的 hack，创建两个工件（一个供最终用户使用，另一个供开发人员使用）闻起来更好。
（最后，我不知道它是什么类型的库/应用程序，但在我的工作环境中，如果库将数据发送到第三方服务器是不可接受的。你确定你真的需要这样做？）
【讨论】：