Hi Daniel and all,
With my PMC hat on, I'm +1 on implementing this PR. "The show must go
on" as they say.
I also see no reason this should wait for 5.0, there is nothing special
about v5 that I know of, it's just a number.
The PR is indeed quite large and it has the potential to "inconvenience"
any release, should we postpone it.
I am a bit weary it may break some things and/or catch some users
unprepared that may rely on log4j (v1) specifics, but at the end of the
day it's "just" logging and any healthy open source project needs to
make progress.
The one issue I have - as a non-coder - is that there could have been
better comms around this issue on the mailing list, I'm not great at
following Github developments.
My 2 pence,
Lucian
On 2023-05-01 14:27, Daniel Salvador 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.
