I agree. Even if we don't fully understand every minute technical detail of Log4J 2 vs. Log4J 1, I think we've learned enough from my work-in-progress patch to declare that a migration is too risky for the 3.5 line. Reverting ZOOKEEPER-1371 (the earlier backwards-incompatible logging change) is the better choice for the interest of proceeding with 3.5 releases.
--Chris Nauroth On 3/15/16, 11:23 AM, "Patrick Hunt" <[email protected]> wrote: >I just commented on ZOOKEEPER-2342... not sure I fully understand all >the issues to be honest. Given how much we're trying to do in 3.5 it >seems like it would be prudent to wait on 1371 until 3.6... IMO. :-) > >Patrick > >On Tue, Mar 15, 2016 at 11:15 AM, Chris Nauroth ><[email protected]> wrote: >> At this point, I am +1 for a revert of the patch that introduced the >> problem (ZOOKEEPER-1371). We need more time to come up with a migration >> path to Log4J 2 that minimizes impact on operators. That will take >>time, >> and I'd prefer that we don't hold up 3.5.2-alpha for it. >> >> --Chris Nauroth >> >> >> >> >> On 3/15/16, 11:08 AM, "Patrick Hunt" <[email protected]> wrote: >> >>>Hi folks, can we prioritize getting logging fixed? It's causing test >>>failures, e.g.: >>>https://builds.apache.org/job/ZooKeeper-trunk/2850/artifact/trunk/build/ >>>tm >>>p/zk.log >>> >>>This is the jira: >>>https://issues.apache.org/jira/browse/ZOOKEEPER-2342 >>> >>> >>>Perhaps we should revert the change that caused this in the first place. >>> >>>Patrick >>> >> >
