curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <>
Subject Re: EnsurePath constructor
Date Mon, 16 Sep 2013 19:43:47 GMT
I see - yeah that is pretty ugly. That's some of the oldest code in Curator as well. Since
that class was created, I actually prefer creatingParentsIfNeeded() to EnsurePath. creatingParentsIfNeeded()
only executes when ZK throws NoNodeException. I wonder if EnsurePath should be deprecated.


On Sep 16, 2013, at 2:37 PM, John Vines <> wrote:

> Sorry, didn't mean constructor but the ensure() call. With the construction through newNamspaceAwareEnsurePath
(which could probably stand to be documented better, as the EnsurePath doc page mentions the
existance of a method and links to the CuratorFramework docs which have no mention of it whatsoever),
it does seem strange to have to provide a CuratorZookeeperClient considering you're creating
it through the CuratorFramework. I just wonder if there should be an extension/wrapper in
curator-framework or higher that is more code friendly.
> On Mon, Sep 16, 2013 at 3:00 PM, Jordan Zimmerman <>
> 1. It's in the curator-client project, not curator-framework (i.e. it's low level)
> 2. Because of namespaces, users should call CuratorFramework.newNamespaceAwareEnsurePath()
instead of directly allocating an EnsurePath object.
> -JZ
> On Sep 16, 2013, at 1:55 PM, John Vines <> wrote:
> > Is there a particular reason the EnsurePath constructor takes in
> > CuratorZookeeperClient instead of a CuratorFramework like a lot of the
> > other curator items? I thought about making a ticket, but I figured it was
> > better to ask first.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message