Re: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.

[Volkan Yazıcı]

ZOOKEEPER-2342 points to ZOOKEEPER-4427, landing the Log4j 1 to Logback
changes. In the latter ticket, there is a discussion thread linked
. 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  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.  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.  

Re: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.

[Gary Gregory]

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
> . 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  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
> > >

Re: [jira] [Resolved] (ZOOKEEPER-2342) Migrate to Log4J 2.

[Carter Kozak]

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

2.17.2 release

[Jason Wen]

Hi,

I a newbie who just joined the mailing list.

Recently I am working on log4j1 to log4j2 migration using the bridge approach, 
but we find that it has a bug when using NullAppender. This issue looks like 
fixed in the upcoming version 2.17.2.

I see that most of the jira issues target for 2.17.2 have been resolved/closed, 
with 1 in progress and 1 open for documentation.
https://issues.apache.org/jira/projects/LOG4J2/versions/12351179

My questions are:

  1.  Are there any other jira issues to be included to 2.17.2 release?
  2.  Is there an estimation on 2.17.2 release date? Any rough estimation is 
appreciated.

Thanks,
Jason

Re: 2.17.2 release

[Matt Sicker]

The main one I can think of is
https://issues.apache.org/jira/browse/LOG4J2-3394 though there could
be others. I'd estimate that we'll be doing this release sometime this
month.

On Fri, Feb 11, 2022 at 10:36 AM Jason Wen
 wrote:
>
> Hi,
>
> I a newbie who just joined the mailing list.
>
> Recently I am working on log4j1 to log4j2 migration using the bridge 
> approach, but we find that it has a bug when using NullAppender. This issue 
> looks like fixed in the upcoming version 2.17.2.
>
> I see that most of the jira issues target for 2.17.2 have been 
> resolved/closed, with 1 in progress and 1 open for documentation.
> https://issues.apache.org/jira/projects/LOG4J2/versions/12351179
>
> My questions are:
>
>   1.  Are there any other jira issues to be included to 2.17.2 release?
>   2.  Is there an estimation on 2.17.2 release date? Any rough estimation is 
> appreciated.
>
> Thanks,
> Jason

Re: 2.17.2 release

[Ralph Goers]

My hope is sooner than that.

Ralph

> On Feb 11, 2022, at 9:49 AM, Matt Sicker  wrote:
> 
> The main one I can think of is
> https://issues.apache.org/jira/browse/LOG4J2-3394 though there could
> be others. I'd estimate that we'll be doing this release sometime this
> month.
> 
> On Fri, Feb 11, 2022 at 10:36 AM Jason Wen
>  wrote:
>> 
>> Hi,
>> 
>> I a newbie who just joined the mailing list.
>> 
>> Recently I am working on log4j1 to log4j2 migration using the bridge 
>> approach, but we find that it has a bug when using NullAppender. This issue 
>> looks like fixed in the upcoming version 2.17.2.
>> 
>> I see that most of the jira issues target for 2.17.2 have been 
>> resolved/closed, with 1 in progress and 1 open for documentation.
>> https://issues.apache.org/jira/projects/LOG4J2/versions/12351179
>> 
>> My questions are:
>> 
>>  1.  Are there any other jira issues to be included to 2.17.2 release?
>>  2.  Is there an estimation on 2.17.2 release date? Any rough estimation is 
>> appreciated.
>> 
>> Thanks,
>> Jason