ZOOKEEPER-2342 points to ZOOKEEPER-4427, landing the Log4j 1 to Logback
changes. In the latter ticket, there is a discussion thread linked
<https://lists.apache.org/thread/1ktv03wvqtfg22d13c1yo1lgnjv6xpkt>. I was
genuinely curious about their rationale with the hope that maybe we can
learn something to improve in Log4j 2. My conclusions are as follows:
- There was significant reluctance for such a move due to various reasons
- Even though all these objections were shared with their associated
rationale; there were no -1
- People find recent Log4j 2 vulnerabilities a fiasco; hence the
knee-jerk reaction(?)
- People think Log4j 2 is bloated
- Andor Molnar thinks
- Logback is faster (judging from a StackOverflow post)
- Logback Translator <https://logback.qos.ch/translator/> is a good
thing
- There is a Logback PR pending (via Andor Molnar), piling-up Log4j 1
CVEs, and no other alternatives; PR gets merged
I want to share my thoughts on certain points I derived above:
*Log4j 2 is bloated*
I think the modularization in Log4j 3 will greatly address this concern.
Making plugins conditional via properties will enhance this further. I
would have said we are covered here, but I doubt that. We have been trying
to release Log4j 3 for the last 2 years? I guess we need to prioritize this.
*Logback is faster*
Logback was known to be slower than Log4j 2, though according to the most
recent benchmarks Ceki published, this is not the case anymore. Last year I
tried to emphasize the importance of this. The testing methodology, the
results, the credibility, etc. These all don't matter from a user
perspective. Logback has benchmarks indicating they perform better and
Log4j doesn't have a response to this. This is all that a user sees. See
how ZK's Logback migration took place? No facts, but StackOverflow posts
and common misconceptions.
Carter has already landed plenty of commits to improve the situation.
Though `CharsetEncoder` lagging behind `String.getBytes()` in Java 11
really stabbed us badly. AFAIK, this is evened out in newer Java versions.
In conclusion, this is an area we need to fight and win. Otherwise, wins in
other fronts will simply not matter from the point of view of users. Call
me a chauvinist, but the brutal truth is we need to show people graphs
where Log4j kicks some ass.
*Logback Translator is a good thing*
This is a really good example to evaluate our assumptions about how much
users really care about the disruption during a major upgrade. We put
tremendous effort into making a tool work seamlessly against an ancient
version, yet people are happy with simply changing a couple of lines of
configuration. Gary did a terrific job in log4j-1.2-bridge and I fully
support this effort. Though I think we can interpret these kinds of
observations as a positive indicator for dropping certain modules in Log4j
3. For instance, we need to educate people that logging YAML (i.e.,
`YamlLayout`) is not a good thing and they should stop doing it. Looking
for the Liquibase Log4j driver? Check out the Liquibase project. Spring
Boot goodies? `spring-boot-starter-log4j2` it is. We need to drop some
weight, IMHO.
On Wed, Feb 9, 2022 at 9:16 PM Gary Gregory <[email protected]> wrote:
> FYI
>
> ---------- Forwarded message ---------
> From: Chris Nauroth (Jira) <[email protected]>
> Date: Wed, Feb 9, 2022, 14:11
> Subject: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.
> To: <[email protected]>
>
>
>
> [
>
> https://issues.apache.org/jira/browse/ZOOKEEPER-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Chris Nauroth resolved ZOOKEEPER-2342.
> --------------------------------------
> Resolution: Won't Do
>
> ZOOKEEPER-4427 has been committed to migrate to Logback in a new major
> version (with the option to swap out the SLF4J back-end if users prefer
> Log4J 2). For prior version lines, discussion is under way on the dev
> mailing list considering reload4j and the new bridge released by Apache
> Logging.
>
> I'm going to close out this issue, because there is no longer community
> interest in the earlier Log4J 2 migration work from a few years ago. Thank
> you to everyone who participated on this issue.
>
> > Migrate to Log4J 2.
> > -------------------
> >
> > Key: ZOOKEEPER-2342
> > URL:
> https://issues.apache.org/jira/browse/ZOOKEEPER-2342
> > Project: ZooKeeper
> > Issue Type: Bug
> > Reporter: Chris Nauroth
> > Assignee: Chris Nauroth
> > Priority: Major
> > Attachments: ZOOKEEPER-2342.001.patch
> >
> >
> > ZOOKEEPER-1371 removed our source code dependency on Log4J. It appears
> that this also removed the Log4J SLF4J binding jar from the runtime
> classpath. Without any SLF4J binding jar available on the runtime
> classpath, it is impossible to write logs.
> > This JIRA investigated migration to Log4J 2 as a possible path towards
> resolving the bug introduced by ZOOKEEPER-1371. At this point, we know
> this is not feasible short-term. This JIRA remains open to track long-term
> migration to Log4J 2.
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.1#820001)
>
