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 <vi...@apache.org> 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 > <jor...@jordanzimmerman.com> 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 <vi...@apache.org> 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. > >
