On Tue, Oct 20, 2020 at 1:18 PM Tamas Penzes <tam...@cloudera.com.invalid> wrote:
> 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. > > What would a migration look like? Could we provide sufficient help for people to easily migrate? It's not clear to me - if someone is using zk as a client library and we upgrade log4j to log4j2 do they also need to upgrade the code they are writing? (the code depending/using the zk jars). I suspect embedding of zk server is also a possibility, although less common, what would the impact be there? I believe the answer should be only the configs but perhaps we should experiment, say by doing a poc with hbase (any project relying on zk) and then comparing the impact? Patrick > 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 > > > > > >
