-
Notifications
You must be signed in to change notification settings - Fork 1.2k
CURATOR-718: Refactor CuratorFramework inheritance hierarchy by composing functionalities #517
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
CURATOR-718: Refactor CuratorFramework inheritance hierarchy by composing functionalities #517
Conversation
ff34371
to
c2195e1
Compare
I leave CURATOR-710 to #508. To resolve CURATOR-710, I think we need to decide whether |
c2195e1
to
3ecccc6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a huge pr. But most changes are migrating references from CuratorFrameworkImpl
to InternalCuratorFramework
so we can customize functionalities by overriding methods in InternalCuratorFramework
but not CuratorFrameworkImpl
. Now, there will be only one CuratorFrameworkImpl
per curator client.
* | ||
* <p>An instance of {@link CuratorFramework} MUST BE an instance of {@link InternalCuratorFramework}. | ||
*/ | ||
public abstract class InternalCuratorFramework implements CuratorFramework { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the most notable change.
NamespaceFacade
and WatcherRemovalFacade
are now subclasses of DelegatingCuratorFramework
and InternalCuratorFramework
but not CuratorFrameworkImpl
.
@@ -98,15 +97,13 @@ public void flappingTest() throws Exception { | |||
} finally { | |||
try { | |||
leaderSelector1.close(); | |||
} catch (IllegalStateException e) { | |||
fail(e.getMessage()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kezhuw would you consider this is a release blocker? I may expect to call a release by the end of Feb. and now try to collaborate to converge the ongoing PRs. |
No. It is not even a bug. |
288799c
to
2cb13cf
Compare
…sing functionalities Currently, the `CuratorFrameworkImpl` hierarchy is neither simple nor composable. Ideally, there should be only one instance of `CuratorFrameworkImpl`. Additional functionalities should be added by intercepting methods on purpose, but not by cloning through `CuratorFrameworkImpl(CuratorFrameworkImpl parent)`. We could take CURATOR-626 and CURATOR-710 as lessons to know how brittle the currently hierarchy.
2cb13cf
to
c47cc6f
Compare
} | ||
|
||
@Override | ||
public <DATA_TYPE> void processBackgroundOperation( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public <DATA_TYPE> void processBackgroundOperation( | |
<DATA_TYPE> void processBackgroundOperation( |
.. and may need a re-format
* | ||
* <p>An instance of {@link CuratorFramework} MUST BE an instance of {@link InternalCuratorFramework}. | ||
*/ | ||
public abstract class InternalCuratorFramework implements CuratorFramework { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I'd prefer to name it CuratorFrameworkBase
since it's used outside (as method parameter) rather than internal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renamed.
By internal
, I mean it should not be used outside of curator
. Currently, only impls
/details
packages use it. Add it is public for private usages
for caution.
import org.apache.zookeeper.Watcher; | ||
import org.apache.zookeeper.server.quorum.flexible.QuorumVerifier; | ||
|
||
public class DelegatingCuratorFramework extends InternalCuratorFramework { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add some class comment for its purpose?
Also this seems another abstract class rather than an instantiable one. And we don't need impl start
and close
in such a bias.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DelegatingCuratorFramework
is now abstract
and start
/close
has been moved to subclasses.
@Override | ||
public void start() { | ||
throw new UnsupportedOperationException(); | ||
} | ||
|
||
@Override | ||
public void close() { | ||
throw new UnsupportedOperationException(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or somewhat delegate to client.start/close
also?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, only CuratorFrameworkImpl::start
/CuratorFrameworkImpl::close
take effects, start
/close
in other facades throw. I think we should keep this behavior unchanged in an refactor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I noticed that this is the original manner. Then it's fine. (Although I think it's by accident, cc @Randgalt do you remember the reason why we don't delegate here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I don't think NamespaceFacade::close
should close curator.
import org.apache.zookeeper.Watcher; | ||
import org.apache.zookeeper.server.quorum.flexible.QuorumVerifier; | ||
|
||
public class DelegatingCuratorFramework extends InternalCuratorFramework { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also can be package private.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rest generally looks good to me.
…y composing functionalities Notable changes to last review: 1. Rename `InternalCuratorFramework` to `CuratorFrameworkBase`. 2. Make `DelegatingCuratorFramework` `abstract` and package `private`. 3. Move `start`/`close` from `DelegatingCuratorFramework` to subclasses.
@tisonkun Sorry for being so late! I have pushed a fixup commit to solve the review comments. |
This closes #1233.
Currently, the
CuratorFrameworkImpl
hierarchy is neither simple nor composable.Ideally, there should be only one instance of
CuratorFrameworkImpl
. Additional functionalities should be added by intercepting methods on purpose, but not by cloning throughCuratorFrameworkImpl(CuratorFrameworkImpl parent)
.We could take CURATOR-626 and CURATOR-710 as lessons to know how brittle the currently hierarchy.