The current patch implements the java client side of chroot. After reviewing the code more closely it became clear
that implementing this on the server is much harder/errorprone/inefficient than implementing the core functionality
on the client. This means we don't get enforcement with this JIRA, however ZOOKEEPER-424 was created to
address that feature enhancement.
As it currently stands the client can set a chroot during client (ZooKeeper) object creation which will provide
similar functionality to unix chroot command. See the updated API and forrest docs for details.
I added 3 tests, two of which re-use existing test functionality. I'm validating both the synchronous as well
as async operations.
Note: I made delete("/") have the same semantics w/ or w/o chroot being used. I thought this best, although
not strictly necessary.
Note: /zookeeper is only available if chroot is not used (we don't map it into the chroot for example). I don't think
we would want to do that anyway. but wanted to not it here for review.
When updating the client code I introduced the concept of clientpath and serverpath to make the distinction more
Note that we validate both the chroot path as well as the clientPath, we don't validate the serverpath, assuming
that it's valid. Also this ensures that clientpaths start, for example, with / character
Note: watchregistration objects resulted in a very nice way of mapping client/server paths in watches that don't require
us to do any prefix elimination.
In general I was pretty happy with the (small) number of changes required to implement this and also the decent
test coverage we currently have.
Mahadev should take this next and implement the c client changes, hopefully they will be similar.