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.
> >
>

Reply via email to