That seems to have fixed the namespace issues. There are still 2 tests failing, but these are the ones that Mike has raised JIRA tickets for already, so nothing additional is broken by the 3.0 changes. I will merge into 3.0 now. cheers
On Wed, Aug 19, 2015 at 8:22 AM, Cameron McKenzie <mckenzie....@gmail.com> wrote: > So, it seems that this is an issue with the WatcherNamespaceRemovalFacade. > It doesn't override > > String fixForNamespace(String path, boolean isSequential) > > which means that instead of using the wrapped CuratorFramework namespace, > it uses its own instance (which is null), meaning that the namespace fix > doesn't work. > > I think that this version of the fixForNamespace is a new method on the > CuratorFramework since the CURATOR-217 branch was made. > > Anyway, I have fixed it up and it seems to have fixed things. I'll rerun > all the tests and make sure nothing else is broken then I'll push the > changes. > cheers > > On Tue, Aug 18, 2015 at 1:42 PM, Cameron McKenzie <mckenzie....@gmail.com> > wrote: > >> Seems like a bunch of tests are failing: >> >> >> testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessMultiMutex) >> >> testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessMutex) >> >> testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessSemaphoreMutex) >> testLockACLs(org.apache.curator.framework.recipes.locks.TestLockACLs) >> >> testSimulationWithLocksNamespace(org.apache.curator.framework.recipes.locks.TestReaper) >> >> Tests are still running, and I haven't look into them yet, but it would >> seem based on the test names that something is broken with namespace stuff. >> Will have a look when I get a minute. >> cheers >> >> >> On Tue, Aug 18, 2015 at 1:38 PM, Scott Blum <dragonsi...@gmail.com> >> wrote: >> >>> Cool. You should be able to just push a fix and then fast-foward >>> CURATOR-3.0. >>> >>> On Mon, Aug 17, 2015 at 11:29 PM, Cameron McKenzie < >>> mckenzie....@gmail.com> wrote: >>> >>>> I think it's all good. I've fixed up the couple of build issues on the >>>> 217-merged branch. Just running the unit tests. If everything's ok then >>>> I'll merge it back into CURATOR-3.0 and then I think we're back in a stable >>>> state, and I can start on CURATOR-214. >>>> >>>> On Tue, Aug 18, 2015 at 1:27 PM, Scott Blum <dragonsi...@gmail.com> >>>> wrote: >>>> >>>>> I think just confirm that ZooDefs.CONFIG_NODE is the correct watcher >>>>> path for getConfig()? >>>>> >>>>> On Mon, Aug 17, 2015 at 11:19 PM, Jordan Zimmerman < >>>>> jor...@jordanzimmerman.com> wrote: >>>>> >>>>>> Sorry - it’s hard to follow this thread. What do I need to do? >>>>>> >>>>>> -Jordan >>>>>> >>>>>> >>>>>> >>>>>> On August 17, 2015 at 6:18:21 PM, Cameron McKenzie ( >>>>>> mckenzie....@gmail.com) wrote: >>>>>> >>>>>> Thanks Scott, >>>>>> I've just merged CURATOR-217 into master and have one small issue. >>>>>> >>>>>> Jordan, with the changes you made with to the Watching.java class, the >>>>>> getWatcher() call now takes a CuratorFramework reference and a path >>>>>> reference. >>>>>> >>>>>> The GetConfigBuilderImpl breaks when merging because it's using the >>>>>> old >>>>>> getWatcher() call that doesn't exist any more. This isn't an issue to >>>>>> fix, >>>>>> but I'm just wondering what path reference should be used for the >>>>>> configuration case, as it's a different sort of watch. It's just >>>>>> passed to >>>>>> the getConfig() call on the ZooKeeper class. It seems that I can't >>>>>> just >>>>>> pass in a null path as this gets validated. Suggestions? >>>>>> >>>>>> cheers >>>>>> >>>>>> >>>>>> On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman < >>>>>> jor...@jordanzimmerman.com> wrote: >>>>>> >>>>>> > Great work. Thank you. >>>>>> > >>>>>> > ==================== >>>>>> > Jordan Zimmerman >>>>>> > >>>>>> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dragonsi...@gmail.com> >>>>>> wrote: >>>>>> > > >>>>>> > > This is now done, sorry for the delay. Let me describe the >>>>>> current state >>>>>> > > of the world: >>>>>> > > >>>>>> > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old, >>>>>> > > CURATOR-3.0-temp - these are the old versions of all the >>>>>> branches, we >>>>>> > > should consider pruning them at some point. >>>>>> > > >>>>>> > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased >>>>>> versions >>>>>> > of >>>>>> > > the branches we should stick with. >>>>>> > > >>>>>> > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is >>>>>> nothing >>>>>> > > that has been committed to master that isn't in 3.0 now. >>>>>> > > >>>>>> > > Procedures going forward: >>>>>> > > >>>>>> > > - If you're working on stuff for 2.8 / 2.9, branch from master and >>>>>> > > merge/commit to master. >>>>>> > > >>>>>> > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and >>>>>> > > merge/commit to CURATOR-3.0. >>>>>> > > >>>>>> > > - Periodically, we'll want to get master changes into 3.0. To do >>>>>> this, >>>>>> > *check >>>>>> > > out CURATOR-3.0*, and merge master into that, then push the >>>>>> result after >>>>>> > > fixing conflicts (which should be small / non-existent). *Don't >>>>>> do it >>>>>> > the >>>>>> > > other way, don't check out master and merge 3.0 into it.* >>>>>> > > >>>>>> > > For discussion: there is a *3.0-rejects* branch. One of the >>>>>> commits >>>>>> > there >>>>>> > > is and added System.out.println that I think we don't want. The >>>>>> other >>>>>> > one >>>>>> > > is the work to migrate to fasterxml Jackson. I think we actually >>>>>> want >>>>>> > this >>>>>> > > commit on 3.0. Please take a look and let me know, if we want this >>>>>> > commit, >>>>>> > > we should cherry-pick it onto 3.0. I'm happy to do that. >>>>>> > > >>>>>> > > Everything I did should be reversible, so let me know if I screwed >>>>>> > anything >>>>>> > > up! >>>>>> > > >>>>>> > > --Scott >>>>>> > >>>>>> >>>>> >>>>> >>>> >>> >> >
