Re: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.
That would certainly make local development, PR builds, and the individual component releases easier. However, if each release requires a release of every sub-component, that would be harder to track. I'm in favor of splitting out composable pieces, but we should be cognizant of process changes. Perhaps adapting the process to support this sort of thing, where it's currently easiest to put new components into a single repo/component and Volkan found while working on the maven shadow plugin. -ck On Fri, Feb 11, 2022, at 10:37, Gary Gregory wrote: > 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
Re: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.
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ı 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 > wrote: > > > FYI > > > > -- Forwarded message - > > From: Chris Nauroth (Jira) > > Date: Wed, Feb 9, 2022, 14:11 > > Subject: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2. > > To: > > > > > > > > [ > > > > > 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
Re: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.
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 wrote: > FYI > > -- Forwarded message - > From: Chris Nauroth (Jira) > Date: Wed, Feb 9, 2022, 14:11 > Subject: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2. > To: > > > > [ > > 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. Withou
Re: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.
No. Category B dependencies do not need to be optional. They simply need to be called out in the NOTICES file. Ralph > On Feb 10, 2022, at 10:32 AM, Matt Sicker wrote: > > They _can_ be included as binaries, though they require calling out. > I've generally been under the impression that dependencies on cat B or > X need to generally be optional. Though the security issues with v1 > are a larger concern, agreed. > > On Thu, Feb 10, 2022 at 10:46 AM Ralph Goers > wrote: >> >> I’m not sure I understand your concern. Category B licensed works can be >> included as binaries. >> >> However, I expressed a concern on this Jira issue about projects that >> believe they are OK using reload4j since we are still getting security >> vulnerability reports for Log4j 1. >> >> >> Ralph >> >>> On Feb 9, 2022, at 6:54 PM, Matt Sicker wrote: >>> >>> I’m not sure how any PMCs are getting away with distributing Logback as >>> it’s under class B licenses. More info: >>> https://www.apache.org/legal/resolved.html#category-b >>> >>> — >>> Matt Sicker >>> >>>> On Feb 9, 2022, at 14:16, Gary Gregory wrote: >>>> >>>> FYI >>>> >>>> -- Forwarded message - >>>> From: Chris Nauroth (Jira) >>>> Date: Wed, Feb 9, 2022, 14:11 >>>> Subject: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2. >>>> To: >>>> >>>> >>>> >>>> [ >>>> 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) >>
Re: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.
They _can_ be included as binaries, though they require calling out. I've generally been under the impression that dependencies on cat B or X need to generally be optional. Though the security issues with v1 are a larger concern, agreed. On Thu, Feb 10, 2022 at 10:46 AM Ralph Goers wrote: > > I’m not sure I understand your concern. Category B licensed works can be > included as binaries. > > However, I expressed a concern on this Jira issue about projects that believe > they are OK using reload4j since we are still getting security vulnerability > reports for Log4j 1. > > > Ralph > > > On Feb 9, 2022, at 6:54 PM, Matt Sicker wrote: > > > > I’m not sure how any PMCs are getting away with distributing Logback as > > it’s under class B licenses. More info: > > https://www.apache.org/legal/resolved.html#category-b > > > > — > > Matt Sicker > > > >> On Feb 9, 2022, at 14:16, Gary Gregory wrote: > >> > >> FYI > >> > >> ------ Forwarded message ----- > >> From: Chris Nauroth (Jira) > >> Date: Wed, Feb 9, 2022, 14:11 > >> Subject: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2. > >> To: > >> > >> > >> > >>[ > >> 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) >
Re: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.
I’m not sure I understand your concern. Category B licensed works can be included as binaries. However, I expressed a concern on this Jira issue about projects that believe they are OK using reload4j since we are still getting security vulnerability reports for Log4j 1. Ralph > On Feb 9, 2022, at 6:54 PM, Matt Sicker wrote: > > I’m not sure how any PMCs are getting away with distributing Logback as it’s > under class B licenses. More info: > https://www.apache.org/legal/resolved.html#category-b > > — > Matt Sicker > >> On Feb 9, 2022, at 14:16, Gary Gregory wrote: >> >> FYI >> >> -- Forwarded message - >> From: Chris Nauroth (Jira) >> Date: Wed, Feb 9, 2022, 14:11 >> Subject: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2. >> To: >> >> >> >>[ >> 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)
Re: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.
I’m not sure how any PMCs are getting away with distributing Logback as it’s under class B licenses. More info: https://www.apache.org/legal/resolved.html#category-b — Matt Sicker > On Feb 9, 2022, at 14:16, Gary Gregory wrote: > > FYI > > -- Forwarded message - > From: Chris Nauroth (Jira) > Date: Wed, Feb 9, 2022, 14:11 > Subject: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2. > To: > > > > [ > 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)
Fwd: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.
FYI -- Forwarded message - From: Chris Nauroth (Jira) Date: Wed, Feb 9, 2022, 14:11 Subject: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2. To: [ 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)
