WRT bloat, we could take the Maven approach and migrate some features to separate repositories on their own lifecycles. I'm generally not that fan due to the extra churn but it might be worth considering.
Gary On Fri, Feb 11, 2022, 10:22 Volkan Yazıcı <[email protected]> wrote: > 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) > > >
