Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
2.8.2
-
None
-
Tomcat 8.5.20, Oracle Java 1.8.0_144
Description
On most servlet containers, the only way to redirect JUL calls to Log4j is by setting the java.util.logging.manager=org.apache.logging.log4j.jul.LogManager system property globally. This often breaks the native logging of the container, and could also break other apps on the same container do not use Log4j 2. This also requires changing the container's settings and cannot be expressed in the app itself.
Another approach (used by slf4j) is to implement java.util.logging.Handler and then install this handler at the root logger, either programmatically by calling LogManager.getLogManager().getLogger("").addHandler(...) or by changing logging.properties at the JRE level. This also breaks the container's native logging and other apps, but in different ways than LogManager. I do not advocate this approach, but it's useful to know about it as a background for this feature request.
(tl;dr: It's impossible to reliably redirect JUL from a webapp without creating a mess).
Thankfully, Tomcat has a solution for this: Tomcat JULI allows per-webapp configuration by adding a WEB-INF/classes/logging.properties file with handlers=some.custom.Handler inside it. This will redirect JUL calls from this webapp (and this webapp only) to that handler, and that handler then can redirect to Log4j.
In short: Add a java.util.logging.Handler implementation that redirects to Log4j so that webapps can use Tomcat's per-webapp configuration and avoid the JUL mess.
