Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ZOOKEEPER-2642] Resurrect the reconfig() methods that were in ZooKeeper.java. #122

Closed
wants to merge 6 commits into from

Conversation

Randgalt
Copy link
Member

Resurrect the reconfig() methods that were in ZooKeeper.java. While 3.5.x is an alpha there are clients in production that are relying on the current specification. The reconfig() methods are marked deprecated to inform that they will be removed later. The "new" methods in the new class ZooKeeperAdmin were renamed reconfigure() to avoid getting the deprecation annotation inherited and to provide clarity. Both reconfig() and reconfigure() are implemented via protected methods in ZooKeeper.java

….5.x is an alpha there are clients in production that are relying

on the current specification. The reconfig() methods are marked deprecated to inform that they will be removed later. The "new" methods
in the new class ZooKeeperAdmin were renamed reconfigure() to avoid getting the deprecation annotation inherited and to provide clarity.
Both reconfig() and reconfigure() are implemented via protected methods in ZooKeeper.java
@hanm
Copy link
Contributor

hanm commented Dec 12, 2016

Please also update the reconfig documentation about deprecating old API and about the new API in ZooKeeperAdmin:
https://github.com/apache/zookeeper/blob/master/src/docs/src/documentation/content/xdocs/zookeeperReconfig.xml#L299

Other than this, the patch lgtm.

import org.apache.zookeeper.proto.SetDataResponse;
import org.apache.zookeeper.proto.SyncRequest;
import org.apache.zookeeper.proto.SyncResponse;
import org.apache.zookeeper.proto.*;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remember well, Patrick Hunt once told me during a code review that we should use explicit imports instead of wildcards. Right, @phunt ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@@ -2910,4 +2923,49 @@ private ClientCnxnSocket getClientCnxnSocket() throws IOException {
throw ioe;
}
}

protected byte[] internalReconfig(String joiningServers, String leavingServers, String newMembers, long fromConfig, Stat stat) throws KeeperException, InterruptedException
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: inconsistent brace style for method names from line onwards.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed


<para>Note: for temporary backward compatibility, the reconfig() APIs will remain in ZooKeeper.java
where they were for a few alpha versions of 3.5.x. However, these APIs are deprecated and users
should move to the reconfig() APIs in ZooKeeperAdmin.java.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small typo: reconfig() should be reconfigure().

@fpj
Copy link
Contributor

fpj commented Jan 11, 2017

Just so that I understand, when are we going to be removing these deprecated methods, in trunk? I'm asking this for two reasons:

  1. So that users know in which version these methods are going away
  2. What changes we need to apply to trunk. In trunk, we would need to at least change in the admin class reconfig() to reconfigure(), but it sounds like we don't need to bring back the old reconfig methods.

@hanm
Copy link
Contributor

hanm commented Jan 11, 2017

when are we going to be removing these deprecated methods, in trunk

Maybe when we get a stable release of 3.5?

it sounds like we don't need to bring back the old reconfig methods.

Agree, for trunk the change would be just rename ZooKeeperAdmin::reconfig to ZooKeeperAdmin::reconfigure so it's consistent with branch-3.5 (with some documentation updates and tests update.).

@hanm
Copy link
Contributor

hanm commented Jan 16, 2017

I think this patch is ready to land... @fpj What do you think?

@fpj
Copy link
Contributor

fpj commented Jan 16, 2017

@Randgalt

when are we going to be removing these deprecated methods, in trunk
Maybe when we get a stable release of 3.5?

Are you OK with us removing the deprecated methods when 3.5 becomes GA?

Agree, for trunk the change would be just rename ZooKeeperAdmin::reconfig to ZooKeeperAdmin::reconfigure so it's consistent with branch-3.5 (with some documentation updates and tests update.).

We need to either create a new issue or have a different pull request for 3.5 under this same issue. I'd rather do the latter just so that we wrap this up in one shot, but it depends on whether @Randgalt is willing to do it.

@Randgalt
Copy link
Member Author

Randgalt commented Jan 16, 2017

Are you OK with us removing the deprecated methods when 3.5 becomes GA?

No. I'd vote against that. Breaking changes should be in a 3.6 version. That was the genesis of this issue to begin with. Regardless of the intent of the ZK team, 3.5.x has been in production in a large number of companies for years now. To break a public API without increment the version will cause unnecessary problems.

@Randgalt
Copy link
Member Author

FYI - my PR/patch does rename to reconfigure().

@hanm
Copy link
Contributor

hanm commented Jan 17, 2017

Breaking changes should be in a 3.6 version.

Sounds OK to me.

We need to either create a new issue or have a different pull request for 3.5 under this same issue

I think this pull request (122) should target branch 3.5, because it keeps the old API. We need create a new PR that target master which only contain updates to the API name (reconfig -> reconfigure) and some doc / test updates without bringing back the old APIs.

@Randgalt Could you update the base branch of this PR to be branch-3.5 instead of master? I think this PR is ready to land in branch-3.5.

@fpj I can create a new PR target master that only contain API name changes, if @Randgalt does not get ahead of me on this work.

@fpj
Copy link
Contributor

fpj commented Jan 17, 2017

@hanm @Randgalt sounds like a plan, let's follow the steps that Michael lined up above.

@Randgalt
Copy link
Member Author

Will do

@Randgalt
Copy link
Member Author

See #151

@Randgalt
Copy link
Member Author

Do we need a separate issue for the 3.6 change?

@hanm
Copy link
Contributor

hanm commented Jan 17, 2017

Do we need a separate issue for the 3.6 change?

No we don't (what @fpj prefers wrapping both PR in one shot under ZOOKEEPER-2642).

@Randgalt Do you mind update the current PR (#122) so it apply to master, by removing the old reconfig APIs?

@Randgalt
Copy link
Member Author

OK - to be clear, I have PR #151 which applies the legacy API to branch-3.5. Then, I'll rework this PR (against master) to only have the Admin API, right?

@hanm
Copy link
Contributor

hanm commented Jan 17, 2017

@Randgalt Exactly. Thanks!

@hanm
Copy link
Contributor

hanm commented Jan 17, 2017

Just to close the loop here:

The PR for master branch is now: #152
The PR for branch-3.5 is now: #151

asfgit pushed a commit that referenced this pull request Feb 11, 2017
lvfangmin pushed a commit to lvfangmin/zookeeper that referenced this pull request Jun 17, 2018
Was apache#122

Author: randgalt <[email protected]>

Reviewers: Michael Han <[email protected]>

Closes apache#152 from Randgalt/ZOOKEEPER-2642
RokLenarcic pushed a commit to RokLenarcic/zookeeper that referenced this pull request Sep 3, 2022
Was apache#122

Author: randgalt <[email protected]>

Reviewers: Michael Han <[email protected]>

Closes apache#152 from Randgalt/ZOOKEEPER-2642
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants