Log4j2 epic bug: Log4j2 epic bug: Log4j2

There are some friends in the group who say that the company has specially set up a group of 800+ people to deal with…

Fortunately, mitigation measures and solutions were soon available. At the same time, log4j2 officially released the latest speed impact fix. Applications will also be able to implement more stable fixes.

But I’ve seen all kinds of fixes posted in the group, it’s really not pretty… So here is the easiest fix for Spring Boot users.

The simplest way to fix it

Spring-boot-starter-log4j2 can support the latest version 2.15 (rC1). It’s released now.)

However, if you are familiar with the versioning mechanism of Spring Boot components, you do not need to issue a special version to solve this problem. Just add a simple configuration, as shown below:

Yes, it’s as simple as that. Just configure it in pom.xml as follows:

<properties>
    <log4j2.version>2.15.0</log4j2.version>
</properties>
Copy the code

If you are learning the Spring Boot, then recommend a serial years continues to update free tutorial: blog.didispace.com/spring-boot…

Afterword.

I don’t know if you have noticed that the recent several times because of vulnerabilities affect our Spring Boot applications are not the original Spring Boot things.

For example, Log4j2 is not the default logging component used by Spring Boot. So those of you who didn’t change the log component yesterday were in the group watching…

Until now, most of the more serious bugs were caused by another third-party component, as you can guess.

That’s right, Fastjson.

Spring Boot’s default JSON string serialization and deserialization tool is Jackson, not Fastjson. I don’t know when the Fastjson solution became popular (I remember the XML configuration era, probably for performance reasons?). .

Recently, BECAUSE the DD side is still using the original components, so we did not encounter these problems, but also quite comfortable. Therefore, in the end, it is recommended that if there are no special performance requirements, or other original components can not complete the task, then go to another solution to replace the default solution, so that it will be more stable. After all, the default solutions are the most widely used in the ecosystem outside of the Spring official, and they stand the test of time better.

Finally, which Spring Boot default components do you usually replace? Let us know in the comments section

Welcome to pay attention to my public account: program ape DD, share the outside can not see the dry goods and thinking!