JoaoJandre commented on PR #7131: URL: https://github.com/apache/cloudstack/pull/7131#issuecomment-1487424992
> I see reload4j actively maintained and developed with commercial backers such as Spotify and Exoscale - https://reload4j.qos.ch/ - @JoaoJandre what benefits do we get from moving to log4j 2.x? Also are there any risks? (it would be challenging to review and validate all the 19-22k changes) Log4j is under by the Apache foundation, which makes us part of it ourselves. Therefore, it seems to be a good opportunity to integrate more with its community. On the other hand, Reload4j's objective is to fix security issues with log4j 1.2.x, which is no longer developed nor maintained: "the reload4j project is a fork of Apache log4j version 1.2.17 with the goal of fixing pressing security issues". Why should ACS be stuck with a very old version of log4j which will not receive any new functionalities? Log4j2 has new features that could offer some benefit to ACS: - Async Loggers - performance similar to logging switched off - Custom log levels - Automatically reload its configuration upon modification without loosing log events during reconfigurations. - Java 8-style lambda support for lazy logging (which enables methods to be executed only when necessary, i.e.: the right log level) - Log4j 2 is garbage-free (or at least low-garbage) since version 2.6 - Plugin Architecture - easy to extend by building custom components - Log4j 2 API is separated from the Log4j 2 implementation. - Log4j 2 API supports more than just logging Strings: CharSequences, Objects and custom Messages. Messages allow support for interesting and complex constructs to be passed through the logging system and be efficiently manipulated. Users are free to create their own Message types and write custom Layouts, Filters and Lookups to manipulate them. - Concurrency improvements: log4j2 uses java.util.concurrent libraries to perform locking at the lowest level possible. Log4j-1.x has known deadlock issues. - Configuration via XML, JSON, YAML, properties configuration files or programmatically. As for risks, as in security issues, the proposed log4j2 version has no known vulnerabilities. About the number of changes, we waited for the release of 4.18 for this exact motive, we will have plenty of time to naturally validate all of it untill the next release. And if any problems arise, they shouldn't be that hard to fix. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
