Ouch… JUL doesn’t have MDC support.
> On 2022. Jan 12., at 12:48, Andor Molnar <an...@apache.org> wrote: > > Thanks Chris and Christopher for resolving the licensing issue. > > Christopher, sorry for “fiasco” it might have not been accurate to describe > what happened to log4j2 recently. Respect to Apache for responding quickly > and I understand the reason that Ted mentioned why logback responded more > reluctantly, although the problem in logback is far less severe. I also agree > that less CVEs doesn’t mean more secure software. At the same time I believe > less code leads to less CVEs. Maybe not always, but in most cases. > > All in all, I still tend to logback being better choice for ZooKeeper than > log4j2. Mentioning the dependency hell-ish situation at the end of your > e-mail sounds like a con. > > Let’s take a quick look at the other alternatives. > > Pat just opened my eyes recently that JUL (java.util.logging) could actually > be a logging _backend_ of SLF4j instead of facade replacement. The biggest > pro could be that it’s already built in JDK, no need to add further > dependencies. I’m preparing a side-by-side patch for JUL migration just to > see the differences. > > slf4j-simple could still be a viable option. I haven’t heard enough feedback > from the community to say something for sure. (I will only prepare another PR > for that, if I see strong desire from folks here.) > > Andor > > > > >> On 2022. Jan 12., at 1:15, Chris Nauroth <cnaur...@apache.org> wrote: >> >> 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. >>>> >>>> >
