Hello everyone, This upgrade is fundamental, because log4j is deprecated, not possible to make new updates/upgrades.
with log4j2 we can expand, receive new upgrades/updates, with maintenance of a secure environment and evolution. the importance of this is not questionable. Att / Regards Felipe Rossi | BRASCLOUD *CEO - Founder* *Email:* fel...@brascloud.com.br | www.brascloud.com.br Contact + 55 45 99116-0094 / +55 45 3326-4568 [image: Mailtrack] <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&;> Sender notified by Mailtrack <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality11&;> 04/28/23, 10:14:37 AM On Fri, Apr 28, 2023 at 9:58 AM João Jandre Paraquetti <j...@scclouds.com.br> wrote: > In PR #7131 (https://github.com/apache/cloudstack/pull/7131) I have > proposed to normalize ACS's loggers, and more importantly, upgrade the > library log4j to log4j2 version 2.19. > > Log4j2 has a lot of features that could offer benefits 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. > > In my personal experience using it in some other projects, log4j2 is > easier to work with in general, has better performance, and is an active > project with constant development, innovation, and security patches. > Moreover, it is under a well known and trusted open source organization. > > The change proposed in PR #7131 > (https://github.com/apache/cloudstack/pull/7131) has been tested and > validated in a lot of different scenarios by different people. We have > already tested the logging in the management server, usage, agents, and > system VMs; all of that using KVM and Vmware + Veeam. Most feature sets > were tested, create/delete/update VMs, disks, cresate snapshots, user > management and so on. > > The proposal has been discussed since January, 2023 in the PR > (https://github.com/apache/cloudstack/pull/7131), but I have been > requested to bring it to the mailing list. I would love to hear your > opinions on it, also, any reviews to the PR would be welcome.
