The licensing question is resolved. We can state our choice of EPL, and include only the text of EPL.
Chris Nauroth On Mon, Jan 10, 2022 at 1:05 PM Ted Dunning <ted.dunn...@gmail.com> wrote: > > I would add one more point. Logback has roughly benevolent dictator > governance, Log4j is Apache. During the recent kerfuffle, Apache responded > sooner because it only took one of n people to start responding. Logback's > response for quite some time was "that's an Apache problem" even though > they had very similar vulnerability through JNDI. The root cause of the > vulnerability (in my opinion) was feature-itis but the BDFL model caused > logback to lose considerable time before responding effectively. > > My own slightly-more-than-joking preference is to find the logging > framework with the fewest features and options. I seriously doubt if the > speed differences can be measured in a realistic situation and the risk of > feature creep is significant. > > > > > On Mon, Jan 10, 2022 at 6:17 AM Andor Molnar <an...@apache.org> wrote: > >> 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. >> >> 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. >> >>
