Migrating my analytical project from log4j 1.x to log4j 2.x and observed third party dependency as log4j 1.x

Question

Recently, we migrated my project from log4j 1.x to 2.x using below jars. It is using a lot of third-party libraries and it's sub-dependencies using the log4j-1.2.17.jar project. We identified log4j jars with help mvn dependency:tree command and excluded the log4j-1.2.17 jars. Added below dependencies wherever it is using log4j 1.2.17 as project/module dependency jar.

      <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>2.13.0</version>
      </dependency>
      <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-api</artifactId>
        <version>2.13.0</version>
      </dependency>
      <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-slf4j-impl</artifactId>
        <version>2.13.0</version>
    </dependency>
    <dependency>
       <groupId>org.apache.logging.log4j</groupId>
       <artifactId>log4j-1.2-api</artifactId>
       <version>2.13.0</version>
      </dependency>

Excluded log4j jars zookeeper and hadoop-client. Example:

<dependency>
  <groupId>org.apache.zookeeper</groupId>
  <artifactId>zookeeper</artifactId>
  <exclusions>
    <exclusion>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
    </exclusion>
    <exclusion>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-log4j12</artifactId>
    </exclusion>
   </exclusions>
</dependency>

After packaging my project and observed that log4j-1.2.17.jar is in the jars directory of the project. But we did not find in our project as dependency or sub-dependency.

Now, my questions:- If we delete the "log4j-.1.2.17.jar" from the project then Is it impact any functionality of third party libraries?

Kindly provide your suggestion.

Answer 1

In 99% or more of the cases removing the Log4J 1.x jar should cause no problems. However, some libraries try to manipulate logging by calling Log4J internal methods. For the most part those will all be ignored, which shouldn’t cause a problem.