## 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:

- log4j-bridge-VERSION.jar
- logback-classic-VERSION.jar
- logback-core-VERSION.jar
- slf4j-api-VERSION.jar

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 using log4j-bridge in production with success.

### 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 negligible, in a large number of cases where log4j is configured through a configuration file, be it log4j.properties or log4j.xml, log4j-bridge is sufficient to migrate your 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, i.e. neglible. There memory overhead amount 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.