Thanks Enrico. Chris has -1 on the patch. I need to address his comments first and unfortunately cannot promise this week.
A. > On 2022. Jan 10., at 15:30, Enrico Olivelli <eolive...@gmail.com> wrote: > > Andor, > > Il giorno lun 10 gen 2022 alle ore 15:17 Andor Molnar > <an...@apache.org> ha scritto: >> >> Thanks for all the feedback and concerns folks. I’m trying organize them in >> bullet points. Order is random, not importance. >> >> 1) Licence. I’m not familiar with dual-licensing either. Maybe we need >> somebody with better Apache knowledge around this or ask the legal team, I’m >> not sure. Hope this won’t be a blocker for logback. >> >> 2) Compatibility with other projects. "It has taken a long time, but it >> appears that the wider big data >> ecosystem is coming around to Log4J 2.” >> >> The way I see it and to be honest I'm almost always a “go-with-the-flow” guy >> especially when comes to Hadoop, but the recent fiasco is a good example of >> how bad idea it could be sometimes. Thanks Lord that ZooKeeper still hasn’t >> moved to lo4j2 yet which saved me tons of working hours in my employer. >> >> 3) Functionality of log4j2. In a nutshell: YAGNI. You don’t need to >> implement or prepare for something which you don’t need _at the moment_. >> That was my main intention of moving towards logback. Simple, fast, enough. >> >> 4) Performance. slf4j+logback outperforms basically everything: >> https://stackoverflow.com/questions/11359187/why-not-use-java-util-logging >> I haven’t verified it myself, so this might not be rock solid advantage. >> Based on the article and given the amount of work needed to replace the >> logging facade SLF4j with something else like j.u.l. is not the train I >> originally wanted to jump on. >> >> So, I believe the question in this topic is “which default SLF4j logging >> implementation shall ZK ship by default?” >> >> 5) Backward compatibility. That’s something I still need to work on. Logback >> config translator is pretty neat: https://logback.qos.ch/translator/ so, >> upgrading existing config files should not be a problem. Additionally we >> keep log4j1 still an option as the backend. >> >> Apologies I didn’t have time to take a look at slf4j-simple for our tests >> yet, but looks like this option has already got support from multiple folks >> in the community, so worth a shot. > > > I agree. > Let's commit your patch and roll out a 3.8 release within the end of January > > thank you very much > > I am going to merge the LogBack patch in the end of current week if no > one objects > >> >> Thanks >> >> Andor >> >> >> >> >> >> >> >> >> >>> On 2022. Jan 7., at 21:18, Patrick Hunt <ph...@apache.org> wrote: >>> >>> On Fri, Jan 7, 2022 at 12:10 PM Ted Dunning <ted.dunn...@gmail.com> wrote: >>> >>>> I have been watching the private and public mailing lists for Apache >>>> Logging as part of $dayjob as well. >>>> >>>> I read the mood there differently. The most recent comment I remember was a >>>> confirmation that "no bugfixes or security patches are planned for log4j1". >>>> >>>> Log4j2 really is much larger than necessary. This is, in my opinion, the >>>> root cause of the recent farago. >>>> >>>> But having a cutaway by using slf4j is a very reasonable position to take >>>> there. Customers can use log4j2 if they want to or opt for simpler systems. >>>> Our default can be as simple as we like (even just util.logging). >>>> >>>> >>> That is a really good point Ted, one that came to mind a couple weeks ago >>> but I never circled back on - why are we not using util.logging by default? >>> Assuming end users can configure (slf4j) whatever they want. Perhaps we >>> could even ship "samples" for the various options if there is interest... >>> >>> Regards, >>> >>> Patrick >>> >>> >>>> On Fri, Jan 7, 2022 at 9:57 AM Patrick Hunt <ph...@apache.org> wrote: >>>> >>>>> ... >>>>> >>>>> I also see that there is interest (upstream/apache I mean) in >>>>> resurrecting log4j1 - imo that could also be a good path for us.
