鉴于我对SLF4J和java.util.Logging感到困惑，什么是最佳解决方案? [英] Given I'm stuck with SLF4J and java.util.Logging, what is optimal solution?

问题描述

情况:我们使用带有异步附加程序的SLF4j和Log4j 2问题是我们还使用了使用java.util.Logging的JSF.我看到关于使用jul-to-slf4j的性能的各种令人发指的警告，这是因为您不能仅仅因为它在JDK中就放弃了java.util.Logging，而且......这就是 http://www.slf4j.org/legacy.html 说:

Situation: We use SLF4j and Log4j 2 with asynchronous appenders Problem is we also use JSF which uses java.util.Logging. I see all kinds of heinous warnings about performance in regards to using jul-to-slf4j due to the fact that you can't just chuck out java.util.Logging because it's in the JDK and because... well here is what the documentation at http://www.slf4j.org/legacy.html says:

"...因此，从Jul到SLF4J的转换会严重增加禁用的日志记录语句的成本(60倍或6000％)，并显着影响已启用的日志语句的性能(总体增加20％)从Logback版本0.9.25开始，借助LevelChangePropagator可以完全消除禁用日志语句的60倍转换开销."

"...Consequently, j.u.l. to SLF4J translation can seriously increase the cost of disabled logging statements (60 fold or 6000%) and measurably impact the performance of enabled log statements (20% overall increase). As of logback version 0.9.25, it is possible to completely eliminate the 60 fold translation overhead for disabled log statements with the help of LevelChangePropagator."

请注意，无论如何，使用SLF4J + java.util.Logging会使您的性能下降20％，但是您可以使用最新版本放弃60倍的增长.

Note that no matter what, with SLF4J + java.util.Logging you are stuck with 20% performance hit, but you can ditch the 60 fold increase by using a recent version.

20％是不可接受的.

其他想法也受到欢迎和鼓励，但是我想到的解决方案是不合并java.util.Logging.而是使用单独的配置文件，该配置文件指向与其他所有文件相同的日志文件.有没有人知道我在哪里可以找到如何执行此操作的示例(假设这样做并不意味着所有创作都结束了)?

Other ideas are welcomed and encouraged but the solution I have in mind is to simply not consolidate java.util.Logging. Instead, use a separate configuration file that points to the same log file as everything else. Does anyone have or know where I can find an example of how to do this, assuming doing so won't mean the end of all creation?

如果有更好的方法，我愿意接受.

If there's a better way, I'm open to it.

推荐答案

我认为最佳的解决方案是降低20％的性能.如果您没有完全替换JUL类，则LogRecord第一次离开JUL就是Handler.您还需要编写自己的LevelChangePropagator版本，以便在JUL记录器中反映Log4J2中对日志级别的更改(例如，重新配置). (否则60倍的命中率会破坏禁用的日志语句的性能.)

I think the optimal solution is to take the 20% performance hit. If you don't completely replace the JUL classes, a Handler is the first time a LogRecord leaves JUL. You'll also need to write your own version of LevelChangePropagator so that changes to log level (e.g. reconfiguration) in Log4J2 are reflected in the JUL loggers. (Otherwise the 60x hit will murder performance of disabled log statements.)

您可以用自己的JUL类(直接使用SLF4J或Log4J2)替换JUL类，但是由于JUL不在Java认可的标准替代机制所涵盖的软件包列表中，因此您实际上是在谈论在备用模块上运行JVM或接近它的维护复杂性.

You could replace the JUL classes, with your own (that use SLF4J or Log4J2 directly), but since JUL isn't on the list of packages covered by Java Endorsed Standards Override Mechanism, you are effectively talking about running on a alternate JVM or close to it in maintenance complexity.

您可以滚动自定义JSF实现，方法可能是采用开放源代码并将所有JUL调用替换为SLF4J调用.您可以避免性能下降，并且它几乎不会像替换JUL那样困难.您仍将维护JSF分支，尽管如果您限制更改，也许维护分支不会太糟.它也不会覆盖任何其他调用JUL的代码.

You could roll a custom JSF implementation, probably by taking the open source one and replacing all the JUL calls with SLF4J calls. You'd avoid the performance hit, and it wouldn't be nearly as difficult as replacing JUL. You'd still be maintaining a JSF fork, although if you limit your changes maybe maintaining the fork wouldn't be too bad. It wouldn't cover any other piece of code that are calling JUL, either.

这篇关于鉴于我对SLF4J和java.util.Logging感到困惑，什么是最佳解决方案?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！