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

Reply via email to