[
https://issues.apache.org/jira/browse/HBASE-26158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392269#comment-17392269
]
Geoffrey Jacoby commented on HBASE-26158:
-----------------------------------------
A correction: the Kafka minicluster in my example above is using the Kafka
EmbeddedZookeeper class and not sharing a ZK quorum with the HBase minicluster
or custom process. (Which do share with each other) So let's ignore it for this
discussion.
The reason why we can't use curator-test is that there's no way I can see to
inject HBaseTestingUtility with a curator-test TestingServer instead of an
MiniZookeeperCluster. So we have to inject a MiniZookeeperCluster into the
custom process's in-process test harness. The test just wouldn't work with
curator-test. (There _definitely_ isn't a way to do it with the
TestingHBaseCluster, which is one of many reasons I proposed HBASE-26115.)
HBase didn't have a "duty" to make MiniZookeeperCluster -- it could use
curator-test internally and allow tests to inject a TestingServer in the HBTU
-- but it did, and deliberately exposed it as IA.Public, and downstream users
are allowed to rely on that.
It _is_ literally designed to allow end users the ability to start a ZK to
write UT. That's what IA.Public means. :-)
> MiniZooKeeperCluster should not be IA.Public
> --------------------------------------------
>
> Key: HBASE-26158
> URL: https://issues.apache.org/jira/browse/HBASE-26158
> Project: HBase
> Issue Type: Sub-task
> Components: API, test
> Reporter: Duo Zhang
> Priority: Major
>
> End users do not need to test HBase when zookeeper is broken. And if users
> want to start only a zookeeper cluster, they can just use curator-test, so I
> do not think we should expose this class as IA.Public.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)