Our web app runs in a tomcat 9 container and uses Log4j 2.13.3 as logging system.

The web app includes org.apache.xmlgraphics:fop 2.3, which uses apache commons-logging (version 1.2 in our setup instead of 1.0.4 originally used in fop).

This combination has been running for years using log4-jcl, the Commons Logging Bridge, and all commons-logging output correctly went into the files configured by log4j. The configuration is fairly easy, as described in this SO answer

However, for no apparent reason, fop has recently started writing all its (rather verbose) logs to stderr (i.e. directly to catalina.out) instead of the log file configured, but only on some of our systems. We have some 50 tomcat instances running basically identical software and identical system configurations; one third of them still logs correctly.

I assume that commons-logging doesn't find log4j-jcl's implementation of org.apache.commons.logging.LogFactory.

Debugging log4j using Configuration status="trace" doesn't provide any hint of a failure in log4j-jcl or elsewhere.

I'm out of my wits. Any suggestions?

CodePudding user response：

Answering my own question in case it's helpful to others.

I needed to add a file called commons-logging.properties in the classpath, containing one line:

org.apache.commons.logging.LogFactory=org.apache.logging.log4j.jcl.LogFactoryImpl

Kudos to Piotr for his comment about setting org.apache.commons.logging.diagnostics.dest.

Apparently, if the class is not explicitly specified, the implementation of LogFactory that is actually used depends on the (somewhat random) order the classloader loads the potential candidates.

I my webapp a maven dependency brought sl4f along as a transitive dependency, so on some systems slf4j was chosen instead of log4j, but slf4 didn't have a valid configuration and defaulted to STDERR.