Il giorno mer 21 ott 2020 alle ore 04:14 Christopher <ctubb...@apache.org> ha scritto:
> 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). > In my opinion it is only a matter of configuration files and config scripts. We can check for some good migration guides for the configuration files and simply state clearly in the release notes that we did this switch and add a link to the guide (an official guide from log4j people would be the best choice). > > I suspect embedding of zk server is also a possibility, Yes it is a possibility, but as we are using slf4j usually you provide your preferred slf4j imlpementation. Enrico > 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 >
