Hi Daniel, It was just my opinion it is based on the reasons that it is something that we haven't seen any request in the community before and it will create some challenges for the releases, forward-merging bug-fixes and also for any existing integrations that users might be having. To be specific, I'm neutral (0) on this. Great that you want to take up the RM work to address part of those challenges. You have my support. The only thing that I would hope for is to get this tested/merged early to avoid issues at the later stages nearer to the release.
Regards, Abhishek On Mon, 1 May 2023 at 18:58, Daniel Salvador <dvsalvador...@gmail.com> wrote: > 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. > > >
