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