OK - I understand the problem now. I'm not sure how to fix it - I'll need to think about this.
-JZ On Oct 20, 2013, at 6:02 PM, Cameron McKenzie <[email protected]> wrote: > I don't think that that would fix things. It would just mean that no > namespaces would be stripped off events (which may be acceptable, I'm not > sure). > > I think that the problem currently is that there's a single Watcher instance > that handles events across all CuratorFramework instances (the main one and > any NamespaceFacade ones). > > That opens up a whole other can of worms though. If for some reason you had > multiple NamespaceFacade instances at a given time (not sure why you'd want > to do this, but I think that Curator would allow it), Given that your > CuratorListener instances are bound to the 'main' CuratorFramework instance, > you could get problems where the CuratorListener can't uniquely identify the > zNode the event refers to. > > Imagine something like > > /namespace/bla > /namespace/another/bla > > If I have two NamespaceFacade's one with a base of '/namespace' and another > with '/namespace/another' then if the namespaces are stripped from the event > paths, there's no way to distinguish between the two 'bla' zNodes. > > > > On Mon, Oct 21, 2013 at 11:50 AM, Jordan Zimmerman > <[email protected]> wrote: > As I recall, CuratorFrameworkFactory sets the namespace differently than when > you call CuratorFramework.usingNamespace. I'd change the Factory to create > the CuratorFramework and then call usingNamespace on the created instance so > that they match. > > -JZ > > On Oct 20, 2013, at 5:47 PM, Cameron McKenzie <[email protected]> wrote: > >> TIcket is Curator-68 >> >> If you have a direction as to how you'd like to proceed with the fix, I can >> probably help out if you like. >> >> cheers >> Cam >> >> >> On Mon, Oct 21, 2013 at 11:34 AM, Cameron McKenzie <[email protected]> >> wrote: >> I've had a bit more of a look into this and I think that the problem is in >> the Watcher() implementation in the CuratorFrameworkImpl() constructor that >> takes a Builder as an argument. When it processes a WatchedEvent it removes >> the namespace from the event path >> >> unfixForNamespace(watchedEvent.getPath(); >> >> In the case where you've defined the namespace in the builder, this removes >> the namespace prefix. In the case where you're using the NamespaceFacade, >> the namespace of the CuratorFramework instance is null (because it wasn't >> defined in the builder), so the namespace is not stripped off the event. >> >> I guess this is a bug, but I'm not sure what the correct fix is? The easiest >> fix is to just not strip the namespace in both cases. To strip the namespace >> in the NamespaceFacade case will be quite tricky I presume because you've >> got a single Watcher interface handling potentially acting as the backend >> for multiple NamespaceFacade instances. >> >> I'll add a ticket to Jira. >> cheers >> Cam >> >> >> On Mon, Oct 21, 2013 at 11:01 AM, Cameron McKenzie <[email protected]> >> wrote: >> Will do, I'll double check I'm not doing something stupid first though. >> cheers >> >> >> On Mon, Oct 21, 2013 at 11:00 AM, Jordan Zimmerman >> <[email protected]> wrote: >> If I understand what you're saying that would be a bug. If you can, please >> provide a test case and open an issue in Jira. >> >> -Jordan >> >> On Oct 20, 2013, at 4:52 PM, Cameron McKenzie <[email protected]> wrote: >> >> > Not sure if I'm missing something, but it appears that there is a >> > difference in functionality between defining a namespace during using the >> > CuratorFrameworkFactory.builder().namespace("bla") method, and calling >> > usingNamespace("bla") on an instance of the CuratorFramework itself. >> > >> > Both seem to create nodes correctly in ZooKeeper, but the paths for the >> > events are inconsistent. If you using the Builder approach, the paths in >> > the events do not include the namespace. If you use the CuratorFramework >> > usingNamespace() approach, then the namespaces do appear in the event path. >> > >> > Is this by design? Or just a side effect? >> > cheers >> > Cam >> > >> > >> >> >> >> > >
