Hello guys, Thanks, Felipe Rossi for the reply, operators are a vital part of the community and your opinions are of the greatest importance to the project's advancement.
I already did a lot of tests with the patch and I think we are in a good way to place it. I am +1 on it. Regarding Wei's concern, I understand that the surface of change may scare one a bit; however, the naming normalization is necessary to reduce the loggers' declaration using the inheritance concept from object orientation, which is a step toward facilitating future maintenance in the project regarding Log4J2. I agree it can require a large effort for the 4.19 release manager; however, I think it is a good trade-off, and for that, I am willing to be the 4.19 RM. Best regards, Daniel Salvador (gutoveronezi) On Fri, Apr 28, 2023 at 3:21 PM Wei ZHOU <ustcweiz...@gmail.com> wrote: > Hi Joao, > > Thanks for bringing this to our attention. > > I am +1 with log4j 2.x. It is not urgent to me, as we are currently using > reload4j which is still well maintained: > https://mvnrepository.com/artifact/ch.qos.reload4j/reload4j > > My concern is, you have made a huge amount of rename of variables, for > example, s_logger to LOGGER, which will lead to large extra effort for > release managers when merge 4.17/4.18 to 4.19. > > -Wei > > > On Fri, 28 Apr 2023 at 14:58, 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. >
