Personnally, if I were introducing logging to a java program, I would have used logback. It has some nice features that didn't exist when I was using it, such as periodically rescanning the configuration file, which means you can change the log level in a running process without having to restart it. Very useful. And the java developers did a nice job of making it transparent which logging facility you are using (e.g., there's a standard API that they all support) so it's easy to switch between them.
The main reason would be just to avoid log4j on principle. I checked the version that is being used, 2.21.0, and that is supposed to be safe from the 10/10 severity exploit that happened 2 years ago. See the following for explanations of the exploit and which version is safe (2.17.1 and later are safe).
Personnally, if I were introducing logging to a java program, I would have used logback. It has some nice features that didn't exist when I was using it, such as periodically rescanning the configuration file, which means you can change the log level in a running process without having to restart it. Very useful. And the java developers did a nice job of making it transparent which logging facility you are using (e.g., there's a standard API that they all support) so it's easy to switch between them.
The main reason would be just to avoid log4j on principle. I checked the version that is being used, 2.21.0, and that is supposed to be safe from the 10/10 severity exploit that happened 2 years ago. See the following for explanations of the exploit and which version is safe (2.17.1 and later are safe).
https://builtin.com/cybersecurity/log4j-vulerability-explained
https://www.upguard.com/blog/apache-log4j-vulnerability