Abhishek, I do not see why it would be a 5.0 change. Also, ACS 5.0 is a discussion the community has been having for a long time from now and is something we are too far away to achieve consensus.
The patch is important to enable further development for the log management on ACS and facilitate everyone's life while coding and troubleshooting. If you think it is too much work for the RM, I reiterate that I am willing to be the 4.19 RM and conduct/execute all of the work. Best regards, Daniel Salvador (gutoveronezi) On Mon, May 1, 2023 at 4:10 AM Abhishek Kumar <shwst...@apache.org> wrote: > Great work. > Though I feel this is a 5.0 change. I agree with Wei that this would create > too much overhead for upcoming releases. 4.18 was pushed ahead a few months > and we may end up on a similar path. > Also, reload4j is still actively maintained so I don't think this is > urgent. > > Regards, > Abhishek > > On Fri, 28 Apr 2023 at 18:28, 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. >
