Log4j bridge

Recent versions of logback ship with a module called log4j-bridge. It allows log4j users to use logback without changing a single line of code in their existing applications by replacing the log4j.jar file with appropriate jars, as described below.

How does it work?

The log4j-bridge module contains replacements of most widely used log4j classes, namely org.apache.log4j.Category, org.apache.log4j.Logger, org.apache.log4j.Priority, org.apache.log4j.Level, org.apache.log4j.MDC, and org.apache.log4j.BasicConfigurator. These replacement classes redirect all work to their corresponding logback classes.

To use log4j-bridge in your own application, the first step is to locate and then remove log4j.jar replacing it with log4j-bridge.jar which ships with logback. Note that you still need logback-classic and its dependencies for the log4j-bridge to work properly. In summary, here is a list of the required jars:

In most situtations, replacing a jar file is all it takes in order to migrate from log4j to logback.

Note that as a result of this migration, log4j configuration files will no longer be picked up. If you need to migrate your log4j.properties file to logback, the log4j translator might be of help. For configuring logback, please refer to the manual.

We are happy to report that several applications are successfully using log4j-bridge in production.

When does it not work?

The log4-bridge module will not work when the application calls log4j components that are not present in the bridge. For example, direct references to log4j appenders, filters or PropertyConfigurator are not supported by log4j-bridge. While the number of cases where log4j-bridge is insufficient is not completely negligible, in a vast majority of cases where log4j is configured through a configuration file, be it log4j.properties or log4j.xml, log4j-bridge is enough in order to migrate youran application to logback.

What about the overhead?

There overhead of using log4j-bridge instead of log4j directly is relatively small. Given that log4j-bridge immediately delegates all work to logback, the CPU overhead should be negligible, in the order of a few nanoseconds. There is a memory overhead corresponding to an entry in a hasmap per logger, which should be usually acceptable even for very large applications consisting of several thousand loggers. Moreover, given that logback is both much faster and more memory-efficient, the gains made by using logback should compensate for the overhead of using log4j-bridge instead of log4j directly.