Yeah, EnsurePath seems to have a fairly limited use case, now that I think about it. It does make the code a lot tidier, at the very least.
On Mon, Sep 16, 2013 at 3:43 PM, Jordan Zimmerman < [email protected]> wrote: > 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. > > -JZ > > On Sep 16, 2013, at 2:37 PM, John Vines <[email protected]> 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 < > [email protected]> wrote: > > 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 <[email protected]> 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. > > > > > >
