Log4j 1.2 - 2.17.2 bridge and legacy configuration

The recent zero-day log4j2 vulnerabilities have been a quite big fuss in the Java world. Certainly, software companies started to take a bigger interest in what dependencies they are using in their products. Currently, we can now enjoy two secure versions of log4j, namely 2.17.1 and 2.17.2. Yet, some legacy products still use version 1.2 of log4j, which reached EOL in 2015. Moreso, some don't even use the slf4j facade.

In the process of security patching, you can choose to replace the 1.2 with the reload4j library containing the same classes patched for critical bugs. However, the most respectable approach is to fully migrate to the log4j2. The third option is to meet halfway and use the log4j-1.2-api bridge that exposes the old API connecting with the core from version 2.

Aside from the API, log4j2 introduced support for the old configuration as early as 2.13.3. You would have to be careful, since not every configuration item was fully supported. Especially true when combined with custom appenders like apache-log4j-extras (which, by the way, contains some subset of classes from 1.2, making the use of it somewhat questionable).

Note: There are some promising enhancements to be introduced in 2.18 to support more configuration elements from apache-extras like the org.apache.log4j.rolling.RollingFileAppender.

With that in mind, you can either upgrade the configuration or hope to reuse the old one if it is fully supported. One thing to note is the enhancements implemented in 2.17.2 in comparison to 2.17.1. Before, the programmatic way to load the configuration through the bridge was a no-op. The 2.17.2, besides the numerous fixes, also changes this behavior.

If you still have some code that loads the config using the 1.2 API, for example, like this:

DOMConfigurator.configure(filename);
DOMConfigurator.configureAndWatch(configFilename, delay);

You may encounter some unfortunate errors. As mentioned in the migration docs, it is not allowed, but until 2.17.1, it did not have any negative effects. In 2.17.2, it will try to load the 1.x configuration, affecting your approach to the upgrade if you use this interface:

public class DOMConfigurator {
    //2.17.1:
    public static void configureAndWatch(final String configFilename, final long delay) {
    }

    //2.17.2:
    public static void configureAndWatch(final String fileName, final long delay) {
        XMLWatchdog xdog = new XMLWatchdog(fileName);
        xdog.setDelay(delay);
        xdog.start();
    }
    //...
}

When it comes to the system properties, the log4j.configurationFile property known from log4j2 is the preferred source of configuration when using the bridge. You can use the legacy 1.x log4j.configuration property at the same time and smoothly transition to the new format.