Given I'm stuck with SLF4J and java.util.Logging, what is optimal solution?

Question

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:

"...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."

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% is unacceptable.

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.

Answer 1

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.)

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.

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.