Il Gio 13 Gen 2022, 09:48 Andor Molnar <an...@apache.org> ha scritto:
> Providing sample configs for logging backends which we don’t actively > maintain. I don’t this is gonna work. Maybe log4j.properties is already > broken too in some parts, because we don’t have test coverage / active user > base for that. Sounds to me a waste of effort and error-prone practice. > > Using a more powerful backend for tests that we ship with our product > neither makes sense to me. What would be the cons for the maintainers than > using a single solution end-to-end? > At this point I believe that the best choices are: - log4j2: the most used in the ZK ecosystem - logback: very used, simpler - JUL: always available My preference goes to LogBack for the zookeeper tarball (and so the docker images) In my experience there is no need to super advanced configurations, like log4j2 But a framework that is too simple won't work for production (like simple slf4j). Enrico > Andor > > > > > On 2022. Jan 12., at 22:47, Christopher <ctubb...@apache.org> wrote: > > > > On Wed, Jan 12, 2022 at 10:48 AM Andor Molnar <an...@apache.org> wrote: > >> > >> slf4j-simple > >> ~~~~~~~~~~~~ > >> > >> Based on the documenation: > >> "Simple implementation of Logger that sends all enabled log messages, > for all defined loggers, to the console (System.err).” > >> https://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html > >> > >> I see the following problems with this approach and don’t know how to > deal with them: > >> > >> 1) We won’t be able to ship log config examples for > Trace/Audit/File/RollingFile appenders as we did for log4j, because the > simple backend doesn’t support any of them. > > > > Example Java system properties can be provided for slf4j-simple. > > Examples for other runtimes can also be provided. The ability to > > provide examples wouldn't change. To use example configs for other > > runtime implementations, they just might need to be accompanied by > > instructions on swapping out the runtime implementation on the class > > path. Personally, I think the best place for such example configs and > > instructions is as a "how-to" reference on the website, but it could > > exist anywhere you provide documentation. > > > >> > >> 2) Refactoring the tests is problematic, because we cannot capture log > messages in an OutputStream. However this could be circumvented by > capturing log messages on System.err probably. Need to dig more. > > > > Agreed that is problematic. I would avoid trying to capture > > System.err. Although relatively simple to do in Java, it can break > > things in surprising ways sometimes. For tests, I'd still recommend > > using some non-simple implementation for the test class path, > > regardless of what gets put in the distribution. Logback is as good as > > any for the tests, and you've already done the work for that. > > > >> > >> 3) Lack of MDC support is a problem with this backend too. We would > have to use BasicMDCAdapter (hell knows how) which I guess requires changes > in the main codebase. > >> > >> My 2 cents still goes for logback. > >> > >> Andor > >> > >> > >> > >> > >>> On 2022. Jan 12., at 16:06, Andor Molnar <an...@apache.org> wrote: > >>> > >>> Ouch… > >>> JUL doesn’t have MDC support. > >>> > >>> > >>> > >>>> On 2022. Jan 12., at 12:48, Andor Molnar <an...@apache.org> wrote: > >>>> > >>>> Thanks Chris and Christopher for resolving the licensing issue. > >>>> > >>>> Christopher, sorry for “fiasco” it might have not been accurate to > describe what happened to log4j2 recently. Respect to Apache for responding > quickly and I understand the reason that Ted mentioned why logback > responded more reluctantly, although the problem in logback is far less > severe. I also agree that less CVEs doesn’t mean more secure software. At > the same time I believe less code leads to less CVEs. Maybe not always, but > in most cases. > >>>> > >>>> All in all, I still tend to logback being better choice for ZooKeeper > than log4j2. Mentioning the dependency hell-ish situation at the end of > your e-mail sounds like a con. > >>>> > >>>> Let’s take a quick look at the other alternatives. > >>>> > >>>> Pat just opened my eyes recently that JUL (java.util.logging) could > actually be a logging _backend_ of SLF4j instead of facade replacement. The > biggest pro could be that it’s already built in JDK, no need to add further > dependencies. I’m preparing a side-by-side patch for JUL migration just to > see the differences. > >>>> > >>>> slf4j-simple could still be a viable option. I haven’t heard enough > feedback from the community to say something for sure. (I will only prepare > another PR for that, if I see strong desire from folks here.) > >>>> > >>>> Andor > >>>> > >>>> > >>>> > >>>> > >>>>> On 2022. Jan 12., at 1:15, Chris Nauroth <cnaur...@apache.org> > wrote: > >>>>> > >>>>> The licensing question is resolved. We can state our choice of EPL, > and > >>>>> include only the text of EPL. > >>>>> > >>>>> Chris Nauroth > >>>>> > >>>>> > >>>>> On Mon, Jan 10, 2022 at 1:05 PM Ted Dunning <ted.dunn...@gmail.com> > wrote: > >>>>> > >>>>>> > >>>>>> I would add one more point. Logback has roughly benevolent dictator > >>>>>> governance, Log4j is Apache. During the recent kerfuffle, Apache > responded > >>>>>> sooner because it only took one of n people to start responding. > Logback's > >>>>>> response for quite some time was "that's an Apache problem" even > though > >>>>>> they had very similar vulnerability through JNDI. The root cause of > the > >>>>>> vulnerability (in my opinion) was feature-itis but the BDFL model > caused > >>>>>> logback to lose considerable time before responding effectively. > >>>>>> > >>>>>> My own slightly-more-than-joking preference is to find the logging > >>>>>> framework with the fewest features and options. I seriously doubt > if the > >>>>>> speed differences can be measured in a realistic situation and the > risk of > >>>>>> feature creep is significant. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mon, Jan 10, 2022 at 6: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. > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> 4) Performance. slf4j+logback outperforms basically everything: > >>>>>>> > https://stackoverflow.com/questions/11359187/why-not-use-java-util-logging > >>>>>>> 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?” > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> Thanks > >>>>>>> > >>>>>>> Andor > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> 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. > >
