It's discussed in more depth in the JIRA iirc, but basically; ZooKeeper.java provides client APIs, reconfig is an admiistrative API.
Patrick On Wed, Dec 7, 2016 at 8:48 AM, Jordan Zimmerman <jor...@jordanzimmerman.com > wrote: > I understand the need to make the methods require proper auth but there's > no reason to move it to a different class that I can see. Am I missing > something? > > ==================== > Jordan Zimmerman > > > On Dec 7, 2016, at 4:37 PM, Patrick Hunt <ph...@apache.org> wrote: > > > > This problem has been a long standing blocker issue for 3.5 and > identified > > early on as something that would need to change. This has been one of the > > reasons why 3.5 has stayed in alpha - because we allow non-backward > > compatible changes to new APIs in alpha and we knew we would have to fix > > this. The description/comments of ZOOKEEPER-2014 does a good job > > documenting why this had to change. > > > > Patrick > > > > On Wed, Dec 7, 2016 at 3:18 AM, Jordan Zimmerman < > jor...@jordanzimmerman.com > >> wrote: > > > >> OK - I found the offending issue: ZOOKEEPER-2014 > >> > >> What is the benefit/logic of moving the reconfig() variants into a new > >> class? I can see if this was done from the start but you have now broken > >> Curator in a fairly serious non-backward compatible way for a minor > >> documenting benefit. Does anyone object to me reversing this? > >> > >> -Jordan > >> > >>> On Dec 7, 2016, at 11:37 AM, Jordan Zimmerman < > >> jor...@jordanzimmerman.com> wrote: > >>> > >>> Hi, > >>> > >>> I was compiling Curator against the ZK master and noticed that the > >> reconfig APIs are gone/changed. Can anyone point me at the issues for > this > >> and/or the discussion why this breaking change was made? > >>> > >>> -Jordan > >> > >> >
