This should be a topic that technicians have talked about more recently. Some companies are repairing overnight. At this time, it also reflects the engineering ability of each company. Is it to distribute applications one by one, or can we see the technical strength of each company as long as the middleware level moves.

There are many articles on this topic on the Internet, many of which are about reasons. I won't repeat it here. This article focuses on identification and processing.

1, How to determine whether it has been recruited or repaired

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class Test {

    public static void main(String[] args) {
        Logger logger = LogManager.getLogger(LogManager.ROOT_LOGGER_NAME);
        String cmdMessage = "${jndi:rmi://127.0.0.1:8081/ExportObject}";
        logger.info("log4j2testinfo"+cmdMessage );
        logger.error("log4j2testerror"+cmdMessage );
        logger.warn("log4j2testwarn"+cmdMessage );
    }
    }

If an error is reported after running the above code, there is any lookup error, or if port 8081 is monitored, it indicates that your system has been recruited or has not been repaired;

2, Check whether the dependent library is referenced

Check the dependency tree to see if there are related libraries. Run the following commands:

mvn dependency:tree

If you have the following libraries, you should pay attention to the version. If the version is 2 X to 2.15 0-rc1 shall be repaired in time;

Note that the full name of the class starts with org apache. Logging. If it is directly log4j, it will not affect:

3, Solution

1. Find the corresponding dependent jar package and eliminate it when importing

<dependency>
      <groupId>com.xx.framework</groupId>
      <artifactId>xx-log4j2-starter</artifactId>
      <exclusions>
          <dependency>
              <groupId>org.apache.logging.log4j</groupId>
              <artifactId>log4j-api</artifactId>
          </dependency>
          <exclusion>
              <groupId>org.apache.logging.log4j</groupId>
              <artifactId>log4j-core</artifactId>
          </exclusion>
          <exclusion>
              <groupId>org.apache.logging.log4j</groupId>
              <artifactId>log4j-jul</artifactId>
          </exclusion>
          <exclusion>
              <groupId>org.apache.logging.log4j</groupId>
              <artifactId>log4j-slf4j-impl</artifactId>
          </exclusion>
      </exclusions>
  </dependency>

The following packages are commonly used in the project:

log4j-api

log4j-core

log4j-jul

log4j-slf4j-impl

2. Manually import dependent packages

<dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-core</artifactId>
      <version>2.15.0-RC2</version>
</dependency>
<dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-api</artifactId>
      <version>2.15.0-RC2</version>
 </dependency>
 <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-slf4j-impl</artifactId>
      <version>2.15.0-RC2</version>
 </dependency>
 <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-jul</artifactId>
      <version>2.15.0-RC2</version>
</dependency>

Another way is to modify the relevant parameters and increase the jvm startup parameters

-Dlog4j2.formatMsgNoLookups=true

This is a lazy method, that is, modifying parameters without upgrading jar packages and disabling related functions. This is a temporary scheme and is not recommended for long-term use in production;

4, Summary

The solution is mainly to upgrade the relevant jar packages. Of course, you can temporarily close the relevant functions and then upgrade;

There are many powerful reflection APIs in Java that allow direct compilation of Java code. These are double-edged swords. If you don't use them well, it's easy to get caught. Therefore, if the parameters processed by this API are user input, you need to pay special attention. Like Fastjson, the performance is strong, but it's also easy to be used by hackers. Therefore, all input parameters should be handled safely in the program, It is suggested that requests should be processed uniformly when they come in through interceptors, so as to facilitate unified processing when there are subsequent needs.