Thomas Koch commented on ZOOKEEPER-836:
we can not call it HostSet, because the new class I added isn't a HostSet, it's
a parser for a connectString.
I don't know, what the HostSet you suggest should look like. What's the
difference between a List or Set of InetSocketAddress and a HostSet?
- Should there be any methods on HostSet appart from the normal List/Set
- Should there be a reference to HostSet outside of ClientCnxn to manipulate
HostSet after it has been given to ClientCnxn?
- Should the elements of HostSet be instances of InetSocketAddress or just
pairs of hostname and port? In that case, do we need to prepare for anything
special in regard to IPv6 support?
This issue had to purposes for me:
- Get rid of connectionString parsing in ClientCnxn.
- Separate the HostSet from the chrootPath. IMHO these two things don't belong
together and it was maybe a mistake from the beginning to let the user give the
chrootPath inside of the connectString.
After this patch, I'd like to prepare the next three commits:
- ZOOKEEPER-849: Provide a Path class - This will also affect the
ConnectStringParser, because I'd like it to return a Path instance instead of a
- ZOOKEEPER-838: Chroot is an attribute of ClientCnxn - It is possible, that
only the ZooKeeper object knows about the chroot and ClientCnxn doesn't need to
have any knowledge about it. Thus it can become possible in the long run to
have multiple ZooKeeper objects instantiated using the same ClientCnxn but with
- ZOOKEEPER-837: cyclic dependency ClientCnxn, ZooKeeper - Of course to have
multiple ZooKeeper objects we have to get rid of the ClientCnxn->ZooKeeper
> hostlist as string
> Key: ZOOKEEPER-836
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-836
> Project: Zookeeper
> Issue Type: Sub-task
> Components: java client
> Affects Versions: 3.3.1
> Reporter: Patrick Datko
> Assignee: Thomas Koch
> Attachments: ZOOKEEPER-836.patch
> The hostlist is parsed in the ctor of ClientCnxn. This violates the rule of
> not doing (too much) work in a ctor. Instead the ClientCnxn should receive an
> object of class "HostSet". HostSet could then be instantiated e.g. with a
> comma separated string.
This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.