Hello Vladimir, I feel that it's over engineering here. If we were starting a new project , I would be ok. But this change here and now, does not bring major features to users (I think logging works pretty nicely today), it will even bring more work for them in case they don't know logback.
On a personal point of view, ok log4j2 had CVEs, but it can happen to any project (logback also had one although less impacting), would you be happy to see our users abandon JMeter because a CVE is discovered ? I'll of course reconsider this position if we see no activity in log4j2 in the future. So I am against this change. Regards Philippe On Tue, Dec 21, 2021 at 10:58 AM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Hi, > > What do you think of replacing log4j2 with logback? > > Even though it might sound like an over-reaction, > I believe it is the net positive thing. > > The reasons are: > * log4j2 has lots of features, and we do not really need them > * lots of log4j2 are in-core, so a breach in one of them impacts the whole > application > * log4j2 team seems to treat silent variable substitution (which caused > ${ldap}) a feature, and they tried to keep compatibility for it, so 2.15 > was not enough > * log4j2 team seems to treat "infinite pattern recursion" as a feature > * log4j2 team is not responsible enough to release log4j 1.x that would fix > known security vulnerabilities even though lots of apps can't really > upgrade from 1.x to 2.x > > * logback is developed by Ceki who maintains both slf4j and logback. > That is the integration of slf4j+logback should be much more stable than > slf4j->log4j2 > * logback has a good story regarding the team, feature set, performance. > Ceki incepted (?) log4j, he was a chair of Logging PMC, Ceki incepted slf4j > and logback. > That is a really good story, and it is really hard to beat that. > > So I believe we should migrate off log4j2 as soon as possible. > I can do the migration, however, I would be glad if somebody else steps in > as well. > > Vladimir > -- Cordialement Philippe M. Ubik-Ingenierie