Regarding the license, I'm confident that there will be a path forward. I'm just not confident in my understanding of requirements (if any) to record a choice of EPL instead of LGPL. I decided to file an issue to Legal to get clarity, and I'll keep this thread updated.
https://issues.apache.org/jira/browse/LEGAL-595 Chris Nauroth On Mon, Jan 10, 2022 at 10:05 AM Christopher <ctubb...@apache.org> wrote: > 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. > > >