erm solution
> https://github.com/apache/cloudstack/pull/5878
>
>
>
> Regards.
>
>
> From: Daan Hoogland
> Sent: Wednesday, January 19, 2022 18:23
> To: dev
> Cc: us...@cloudstack.apache.org
> Subject: Re: [DISCUSS] Log4j migration
2022 18:23
To: dev
Cc: us...@cloudstack.apache.org
Subject: Re: [DISCUSS] Log4j migration
As I was involved it shouldn't come as a surprise to anyone that I agree
with Rohit on all he says here.
There was one consideration that we (both) abandoned quite early on; making
a pluggable framework
As I was involved it shouldn't come as a surprise to anyone that I agree
with Rohit on all he says here.
There was one consideration that we (both) abandoned quite early on; making
a pluggable framework for logging in which one can add their own preferred
library. We do not think it is worth the ef
All,
Following log4jshell advisory [1], I want to start a discussion thread around
what next steps should we follow.
Overview: The log4j 1.x has limited feature set and didn't have the same attack
surface as log4j 2.x, this saved the ACS community from log4jshell [1]. In
addition, our uber/fat
