On Mon, Jan 10, 2022 at 9: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.
I'm not a lawyer, but I'm pretty sure we can include a project under a permitted license, regardless of whether the project is made available under other license terms as well. For example, if I write a project and release it under apache-2.0, I could also license it to a customer under custom terms for them. The fact that it's available under those custom terms has no influence over how users use it under the apache-2.0 terms. If you want to be clear about the terms we have selected to use it under, you can clarify that in the LICENSE file in the release tarball, I suppose. > > 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. I'm not sure I would characterize the recent CVEs as a "fiasco". They were reported and fixed. Any project can have vulnerabilities. Trying to avoid projects that have had CVEs likely just means you're avoiding projects that reported and fixed them, and are migrating to less active or more obscure projects that still have vulnerabilities of their own, but aren't necessarily being as frequently or widely reported. You're not necessarily moving to more secure software by avoiding software with CVEs. > > 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. slf4j-simple is even simpler, and faster. log4j2 is highly performant, also, especially when using the optional lock-free asynchronous context selector (https://logging.apache.org/log4j/log4j-2.3/manual/async.html) > > 4) Performance. slf4j+logback outperforms basically everything: > https://stackoverflow.com/questions/11359187/why-not-use-java-util-logging That information is *very* old, and predates log4j2 by a *lot*. Log4j2 was designed using the lessons learned from the logback implementation and the log4j1.2 implementations, and the others. You could call it the evolution of logback. > 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?” I agree that's the right question. > > 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'm not sure how easily slf4j-simple could be used for tests. I think it's more likely that the tests could be switched over to mocking to avoid any kind of logging implementation being a compile-time dependency of tests. slf4j-simple is a good idea for basic logging out of the box if the goal is to have the simplest default implementation bundled in the release's convenience binaries, but it may not work well for tests. That said, you could still keep logback for tests and ship slf4j-simple by default in the binary convenience tarball. They are separate considerations. > > Thanks > > Andor > I think another item that should be on your list that was discussed is the dependency hierarchy. Log4j2 might require a lot of transitive dependencies not already included in ZooKeeper distributions. I suspect it's not many... a lot of dependencies are optional, for optional features that don't need to be included by default. Other dependencies are things like commons-* that are likely already ZK dependencies. > > > > > > > > > > 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. >
