Hi Patrick, I've read the ticket you have linked and also have used my time to ask after log4j2 backward compatibility and got quite negative feedback.
It looks like we don't have a proper solution for it. We are (most probably) able to provide runtime selection of the logging framework, but we would still need a new log4j2 configuration file. There is a bw-compatibility layer of log4j configuration, but my sources told me not to use it as its functionality is very limited and it never became stable enough to use it in production. So the users must create a new log4j config file for log4j2, but I don't think it's a huge problem for ZooKeeper as it is small and its logging configuration isn't complex either. Doing it at the same time as updating ZooKeeper looks feasible and this is why I think we should not invest into the log4j version runtime selection. One day we have to do this step, my question is when? Should we wait for version 4 or can we do it in a "minor release", like 3.7. But ZK minor releases are like major releases on other Apache components. Regards, Tamaas On Thu, Oct 8, 2020 at 8:24 PM Patrick Hunt <ph...@apache.org> wrote: > On Thu, Oct 8, 2020 at 11:00 AM Tamas Penzes <tam...@cloudera.com.invalid> > wrote: > > > Hi All, > > > > I would open a discussion about log4j2 update. > > Would we consider going up to log4j2 in a minor release (e.g. 3.7) or > only > > in a major one, like 4.0? > > The latest log4j1 version (1.2.17) is really old and vulnerable, but > log4j2 > > has a different config format, which means users should adopt their > config > > files when updating ZooKeeper. > > Afaik we are compatible with both of them because of slf4j, but the > default > > is log4j1 at the moment. > > > > What do you think about going up to log4j2 with 3.7? > > > > > Tamaas there's lots of background on this jira: > https://issues.apache.org/jira/browse/ZOOKEEPER-2342 > In particular concern with b/w compat. There is also a patch attached. > > Is there a way we can provide run time selection without impacting code in > a non-bw compatible way? Have other projects been able to solve this? > > Patrick > > > > Thanks, Tamaas > > >