There are two possibilities:
The JDK Logging Adapter is a custom implementation of java.util.logging.LogManager
that uses Log4j. This adapter can be used with either the Log4j API or Log4j Core. When used with the API, there are a couple features of JUL that aren't supported. However, this does allow any other Log4j Provider besides the Core provider to be used with JUL.
The JDK Logging Adapter is dependent on the Log4j API and optionally Log4j Core. For more information, see Runtime Dependencies.
To use the JDK Logging Adapter, you must set the system property java.util.logging.manager
to org.apache.logging.log4j.jul.LogManager
This must be done either through the command line (i.e., using the -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager
argument) or by using System.setProperty()
before any calls are made to LogManager
or Logger
.
The use of a java.util.logging.Filter
is supported on a per-Logger
basis. However, it is recommended to use the standard Filters feature in Log4j instead.
The use of java.util.logging.Handler
classes is NOT supported. Custom Handlers should instead use an appropriate Appender or code their own Appender
plugin.
Java logging levels are translated into Log4j logging levels dynamically. The following table lists the conversions between a Java logging level and its equivalent Log4j level. Custom levels should be implemented as an implementation of LevelConverter
, and the Log4j property log4j.jul.levelConverter
must be set to your custom class name. Using the default LevelConverter
implementation, custom logging levels are mapped to whatever the current level of the Logger
being logged to is using.
Java Level | Log4j Level |
---|---|
OFF | OFF |
SEVERE | ERROR |
WARNING | WARN |
INFO | INFO |
CONFIG | CONFIG |
FINE | DEBUG |
FINER | TRACE |
FINEST | FINEST |
ALL | ALL |
The LogManager is not always usable because you have to set a JVM wide effective system property - e.g. in web servers this is not possible if you are not the administrator.
The Log4jBridgeHandler
is an alternative that can be declaratively used via logging.properties
.
It is less performant than the LogManager but still okay to use: the LogManager replaces the JDK implementation, so your logging code (using JDK syntax) effectively directly uses log4j. When using the BridgeHandler the original JDK implementation along with its configuration (e.g. log levels) is still fully working but the log events are “written” via this handler to log4j as if you would have called log4j.Logger.debug() etc.; it is like a FileHandler but instead of writing to a file, it “writes” to log4j Loggers - thus there is some overhead compared to using LogManager.
The JUL configuration file logging.properties
needs the line
handlers = org.apache.logging.log4j.jul.Log4jBridgeHandler
and JUL logs go to log4j2. Additionally, you typically want to use to following:
org.apache.logging.log4j.jul.Log4jBridgeHandler.propagateLevels = true
In a webapp on Tomcat (and maybe other servers, too), you may simply create a WEB-INF/classes/logging.properties
file with above content. The bridge and the log levels defined in this file are only valid for your webapp and do not have any impact on the other webapps on the same Tomcat instance.
Alternatively you may call Log4jBridgeHandler.install()
inside your webapp's initialization code, e.g. inside ServletContextListener
or a ServletFilter
static-class-init. or contextInitialized()
.
Important: Log levels of JDK should match the ones of log4j. You may do this manually or use the automatic level propagation via Log4jBridgeHandler.propagateLevels = true
.
Please, read the JavaDoc for detailed configuration and limitation information!