1

After Updating log4j - to mitigate the log4shell vulnerability (CVE-2021-44228) - in class path, (or any other library generally), Do I need to restart JVM to make updates get into count?

Here, is mentioned that the "newly added classes" inside class path are getting loaded to the JVM automatically without restart, but what about the classes that are already loaded with the same name via class loader? Do they get overwritten?

The same question applies for tomcat (Although I guess it would be the same as JVM?)

DummyBeginner
  • 411
  • 10
  • 34

2 Answers2

2

Even if the new classpath would immediately be used by the JVM, there may be a number of objects instantiated from the old classes in memory. The new classes would then only apply to new instances. AFAIK log4j would not throw away it's objects during runtime.

To be on the safe side you definitely want to restart the JVM.

Queeg
  • 7,748
  • 1
  • 16
  • 42
2

Is it required to restart JVM after updating log4j in classpath?

Probably yes. It depends on which classloader loads log4j.

If the log4j libraries are exclusively part of your webapps, you might be able to get away with hot-loading all of the webapps.

But you said "in classpath" and I guess that mean's in Tomcat's classpath; i.e. the shared libraries.

My advice would be not to take the risk. Restart Tomcat.

(Your systems should be designed so that Tomcat restarts are not a significant problem. There are various ways to do that. Indeed, one could argue that if downtime of your (single) Tomcat instance is an operational concern, then you should be running multiple copies.)

... but what about the classes that are already loaded with the same name via class loader? Do they get overwritten?

  1. A classloader won't notice things have changed in its classpath. They are not designed to work that way.

  2. And even if it did, a classloader cannot reload a class. The JVM architecture / runtime type safety don't allow it.

  3. The hot-loading feature that (some) people use to avoid Tomcat restarts actually involves creating a brand new classloader to load the new version. The old version of the class will still exist in its original classloader, and other code will remain bound to it.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • By "`in classpath`" I mean a shared library folder which is used by multiple java `jar` files; each runs over an independent JVM. The context consists of multiple JVMs (beside other webapps in tomcat). However, I presume there wouldn't be functional differences between our `jar`s and webapps. – DummyBeginner Jan 26 '22 at 08:12
  • 1
    @DummyBeginner as discussed in [after jar is removed, class is still loaded](https://stackoverflow.com/a/70610164/2711488), it is possible to create a new file under an old name while an already running application keeps using the old file. And in fact, that’s the only mode under which you can replace a jar file already in use by a running JVM without causing errors in the JVM. There’s no way around restarting the JVM(s), especially when it is about a security problem. You don’t want to make guesswork about the presence or absence of the problematic classes. – Holger Jan 26 '22 at 08:42
  • @Holger Thanks, I guessed JVM uses classes from its internal memory (not from the referenced lib every time), and this would be the case till the end of JVM life or GC occurrences. Does your comment mean that JVM fetches the class from its referenced file each time it's needed? (I perceive that from the fact you mentioned, which is replacing the class file with the same name as before will make the JVM use the new class' content) – DummyBeginner Jan 26 '22 at 10:11
  • 3
    @DummyBeginner the JVM will load the class file on its first use or when needed for verifying the correctness of another class referencing it. But more importantly, it will open the *jar file* (not to confuse with class files) when the class loader is created, i.e. at startup. From that point on 1) overwriting the jar file will most likely corrupt it, as the new file has a different structure 2) replacing it (semantically equivalent to deleting the old and creating a new under the same name) will cause the JVM to continue to use the old file. In either case, it won’t load the new classes. – Holger Jan 26 '22 at 10:57