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