Agreed. My choice is not based on the recent vulnerabilities. There probably more to come by the way, so this is not the best timing for log4j2.
Anyway, the main advantage I see for logback is that it's closer to log4j1, hence probably easier to migrate to. ZooKeeper already uses SLF4j so, as you suggested, we should follow the facade / default logging backend approach. Though I believe logback is better for the default. Sometimes less is more and in terms of vulnerabilities less code has less chance for bugs. If logback has all the features which ZooKeeper needs, I think we should choose that. Andor On Wed, 2021-12-15 at 07:41 -0500, Christopher wrote: > I think it would be a mistake to use the recently reported > vulnerability as a basis for migrating to logback. Any dependency can > have a vulnerability, and logback is not substantially different. No > dependency is going to be guaranteed vulnerability-free. Switching on > that basis is a wild goose chase. What is important is that people > respond to vulnerabilities by updating/patching in a timely manner. > > Also, it is my understanding that log4j2 is the evolution of logback > and slf4j, incorporating the original enhancements that logback had > made as a standard slf4j implementation and incorporating them back > into log4j code, as well as providing a lot of additional very useful > features and a huge amount of configuration flexibility. Although > logback is probably still suitable, log4j2 seems to be much more > active, and where the mainline development for Java logging is > happening. Moving to logback from log4j2 seems like a step backwards. > > Most importantly, though, the actual runtime logging implementation > should be independent from ZooKeeper project development. This > project > should use slf4j as a logging facade exclusively, and users should be > able to use whatever slf4j runtime implementation they want. If > ZooKeeper wants to choose a simple implementation, it shouldn't use > logback, but should use slf4j-simple instead. However, I think it > makes more sense to keep log4j2 at runtime for the slf4j > implementation. Users can still change it out for whatever they want. > There's no need to take action to replace the runtime implementation > for slf4j, because users can do that if they want... as long as the > project itself limits its logging to using the slf4j API. > > On Wed, Dec 15, 2021 at 6:46 AM Andor Molnar <an...@apache.org> > wrote: > > > > https://issues.apache.org/jira/browse/ZOOKEEPER-4427 > > > > > > On Wed, 2021-12-15 at 12:35 +0100, Andor Molnar wrote: > > > Sure. I'll take care of that, but first things first. Look what > > > I've > > > found when checking the history of the issue. > > > > > > Thumbs-up from Ceki back from 2016: > > > > > > https://issues.apache.org/jira/browse/ZOOKEEPER-2342?focusedCommentId=15207288&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-15207288 > > > > > > What else do we need? :) > > > > > > Andor > > > > > > > > > > > > > > > On Wed, 2021-12-15 at 12:07 +0100, Enrico Olivelli wrote: > > > > +1 > > > > > > > > Would you like to submit a PR ? > > > > Then we can release 3.8.0 > > > > > > > > Enrico > > > > > > > > Il giorno mer 15 dic 2021 alle ore 12:04 Flavio Junqueira > > > > <f...@apache.org> > > > > ha scritto: > > > > > > > > > We use logback in Pravega, it works fine for us. I'd be ok > > > > > with the > > > > > change. > > > > > > > > > > -Flavio > > > > > > > > > > > On 15 Dec 2021, at 12:02, Andor Molnar <an...@apache.org> > > > > > > wrote: > > > > > > > > > > > > Hi ZK folks, > > > > > > > > > > > > What do you think about migrating ZK to logback? > > > > > > The idea just crossed my mind due to the recent turbulence > > > > > > with > > > > > > log4j. > > > > > > > > > > > > Checking some migrating guides, it doesn’t seem the end of > > > > > > the > > > > > > world. > > > > > > > > > > > > Andor > > > > > > > > > > > > > > > > > > > > > > > > > >
