Sorry, I meant to link to it in my previous reply, but I got distracted and forgot: I also created https://issues.apache.org/jira/browse/LEGAL-594 for the same. I commented on yours to indicate it is effectively a duplicate.
On Mon, Jan 10, 2022 at 1:36 PM Chris Nauroth <cnaur...@apache.org> wrote: > > 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. > > > > >
