On Tue, Oct 20, 2020 at 7:43 PM Patrick Hunt <ph...@apache.org> wrote: > > 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? >
I migrated Accumulo to log4j2 back in February, if you want to see what that looked like: https://github.com/apache/accumulo/pull/1528/files (it's not as bad as it looks... we had a lot of log4j test config files, and some of that PR is related to a logging sink web service that wouldn't apply to ZK; it's mostly just changing config file formats and pom.xml dependency sections). If ZK client code (or an embedded server) is just using slf4j, then ZK does not need to care about what the logging implementation is... users can very easily use whatever they wish by simply ensuring their preferred implementation jars are on the client class path, along with any implementation-specific Java system properties or config files. By default, of course, the implementation jars and config files in the distribution tarball should be log4j2's jars and config file. The biggest hindrance is the internal use of log4j v1 APIs, such as the JMX stuff. In my opinion, that just needs to be removed. ZK should not depend on log4j to provide anything other than a runtime implementation of slf4j. I ran into an issue with that JMX stuff which I addressed in https://github.com/apache/zookeeper/pull/1270 ZK's migration should be much less painful than Accumulo's, but I agree with Tamaas that it's not worth providing any special sauce in ZK to support runtime selection. Luckily, you don't have to... just use slf4j and users already get runtime selection for free. I also don't think it's a big burden to migrate to the new config file format(s) that are available with log4j2 when a user upgrades ZK. For what it's worth, If ZK is ready to make a clean break and drop all log4j v1 stuffs (including ripping out the JMX stuff that is holding it back from being pure slf4j), then I am willing to help with migrating config files and pom.xml dependencies. Christopher
