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