Patrick Hunt commented on ZOOKEEPER-113:

That's a good point Doug, not sure if it's an issue in this case though. I 
don't think we expect users to implement this themselves... anything is 
possible though since we don't specify final.

What got me thinking about this (in addition to the URI idea) is that 
ZooKeeper.java already separates out the message send/recv into a ClientCnxn 
class. If we wanted to have alternate implementations of ClientCnxn (say one 
based on mina/grizzly/blockingio or perhaps some messaging bus architecture) 
our only reasonable option currently would be to create ZooKeeper subclasses 
similar to the comment Ben made originally on this jira (e.g. 
ZooKeeperMina.java). Other options such as passing cnxn in the constructor to 
ZK, or specifying a connection "type" in the constructor are also possible but 
seem less appealing to me.

> ZooKeeper.java should be interface not concrete class.
> ------------------------------------------------------
>                 Key: ZOOKEEPER-113
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-113
>             Project: Zookeeper
>          Issue Type: Improvement
>          Components: java client
>            Reporter: Patrick Hunt
> I think ZooKeeper class in src/java/main should be an interface rather than a 
> concrete class. Among other OO goodness this would give us more flexibility 
> when implementing tests on client code. Would also require something like a 
> factory to be created, which might actually work well with another JIRA we 
> have which is the idea to use a URI(s) rather than a host:port combination 
> when creating zookeeper clients.
> Unfortunately this would have a big impact on clients as it's not b/w 
> compatible (instantiating a new client that is).

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to