Switch all logging to logback

[cwardgar]

Currently we're using log4j2 in TDS and JUL elsewhere ("slf4j-jdk14"). Logback is superior to these in just about every way.

Switching from JUL to logback will be simple, not least because we're not using any logging.properties config files anywhere, which are specific to JUL. Transitioning TDS to logback will be trickier. We actually have some logging code that specifically depends on log4j2.

[JohnLCaron]

Im not sure you should take Ceki's word for it. theres a reason why he has forked twice, and only does one person projects. Having said that, his libraries have been quite good. And hes dedicated his whole life to it (it seems). Just saying maybe see who else is using what.

SLF4J (which is his) of course makes the choice painless, making it a runtime decision. which is good.

Google has developed its own library called flogger, which has very elegant fluid API, and is apparently very performant. Dont think its available outside of google but ill check. It is used in the code to form the log messages, ie not a facade. And it uses standard JUL logging for the actual output. So very different tradeoff. syntax is like:

logger.asWarning().withException(e).log("what %d up %s ?", i, s);

the asWarning() prevents the rest being evaluated if warning is not on, so very efficient.

[cwardgar]

For me, the main benefits of logback vs log4j2 are simpler configuration, saner default behavior when no config is provided, and better documentation. It's a popular choice for newer Java projects as well, such as Gradle.

What issues do we need to be aware of for transitioning TDS from log4j2 to logback? I know a couple:

• TdsMonitor. Would we be okay here as long as we generated log messages in logback with the exact same pattern as those we generated in log4j2?
• LoggerFactorySpecial. Generates Loggers with a custom RollingFileAppender. Seems like a hack: you left the comment all wrong see http://logging.apache.org/log4j/2.x/manual/extending.html. Perhaps there's an easier way to extend in logback (or even log4j2, for that matter).

Anything else you can think of?

[JohnLCaron]

AFAIU, as long as we use slf4j to create the log messages, you can just relink any app, including tdm, with logback.

I just looked and it appears tds 5.0 no longer uses loggerFactory. So i think we can rip it out and then just relink.

No doubt there are some (likely minor) gotchas lurking.

On Sat, Sep 24, 2016 at 12:00 PM, Christian W [email protected] wrote:

For me, the main benefits of logback vs log4j2 are simpler configuration, saner default behavior when no config is provided, and better documentation. It seems to be the popular choice for newer Java projects as well, such as Gradle.

What issues do we need to be aware of for transitioning TDS from log4j to logback? I know a couple:

• TdsMonitor. Would we be okay here as long as we generated log messages in logback with the exact same pattern as those we generated in log4j2?
• LoggerFactorySpecial https://github.com/Unidata/thredds/blob/5.0.0/tdcommon/src/main/java/thredds/util/LoggerFactorySpecial.java. Generate Loggers with a custom RollingFileAppender. Seems like a hack: you left the comment all wrong see http://logging.apache.org/ log4j/2.x/manual/extending.html http://logging.apache.org/log4j/2.x/manual/extending.html. Perhaps there's an easier way to extend in logback (or even log4j2, for that matter).

Anything else you can think of?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Unidata/thredds/issues/646#issuecomment-249378578, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlcwC10GTJbRCjokBR8nqOfwABkyT1Hks5qtWVWgaJpZM4KEsnx .

[cwardgar]

Switching to logback would also fix a problem we're currently having in TDS with log4j2:

08-Nov-2016 15:09:48.168 WARNING [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [thredds] appears to have started a thread named [Log4j2-Log4j2Scheduled-2] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:

See LOG4J2-1259.

[cwardgar]

I nuked the log4j2-specific class in #676, so transitioning to Logback should be straightforward now. Just gotta convert the log4j2 config files to Logback config files.

[cwardgar]

In #987, I switched all of our test code over to using logback, and removed a bunch of log4j2 cruft as well. TDS, TDM, d4ts, and dtswar still use log4j2. The conversion of those products to logback will actually be pretty straightforward (that's the beauty of slf4j). However, I've decided to hold off because it'll require a bunch of doc updates and our docs are in a state of flux right now. So resolution of this issue seems like a 5.1.0 thing.