Hi Kanak, The javadocs on HelixManager state that ConfigChangeListener is deprecated and is replaced by InstanceConfigChangeListener. If the ConfigChangeListener is deprecated shouldn't the GenericHelixController implement the InstanceConfigChangeListener even if the paths are the same? I think the GenericHelixController internally should wrapper/delegate or bridge from the new to the old interface until it gets removed.
I am sure the deprecation was put in place with the intention that the old interface will go away (be removed) in subsequent releases so I imagine you actually want people to reference the new interface in new code/projects that use Helix and not recommend them to reference the old one. That way when time comes you can remove it with less dependencies needing to be realigned. Like I said before IMO the GenericHelixController should implement the new interface so it is clear. As regards the question of me extending that base implementation. At this point I am trying to get an understanding of how Helix works by prototyping. When I saw the new interface it was unclear if I had to implement it myself as it appeared to be so because there were no default implementations. I am hoping I won't have to if the Default implementation works fine for me and I will be perfectly happy to use it. Thanks, Sandeep On Sat, Feb 15, 2014 at 9:33 PM, Kanak Biscuitwala <[email protected]>wrote: > By the way, right now if the default controller is fine for your system, > you don't actually have to instantiate your own GenericHelixController. > HelixManager (when started with instance type CONTROLLER) will do this for > you automatically with all the listeners registered. > > Kanak > > ---------------------------------------- > > From: [email protected] > > To: [email protected] > > Subject: RE: Helix 0.6.2: InstanceConfigChangeListener not implemented > by GenericHelixController > > Date: Sat, 15 Feb 2014 21:30:31 -0800 > > > > Hi Sandeep, > > > > GenericHelixController implements ConfigChangeListener instead of > InstanceConfigChangeListener mostly for backwards compatibility reasons. > Both listeners listen on the same path, so changing an instance config will > still trigger the controller pipeline. Thus, you don't need to extend the > controller just so that it implements this one interface. > > > > May I know why the default controller implementation might fall short in > your system? > > > > Kanak > > > > Date: Sat, 15 Feb 2014 21:23:42 -0800 > > Subject: Helix 0.6.2: InstanceConfigChangeListener not implemented by > GenericHelixController > > From: [email protected] > > To: [email protected] > > > > Hi all, > > > > I am trying to get a prototype going with Helix 0.6.2 and noticed that > the HelixManager instance can take instances of Change Listeners. One of > the new change listeners is InstanceConfigChangeListener. As per the > documentation I can create an instance of the GenericHelixController and > register it as a listener for pretty much all other listeners but not > InstanceConfigChangeListener. > > > > InstanceConfigChangeListener replaces ConfigChangeListener which was > implemented by the GenericHelixController but it does not implement the > InstanceConfigChangeListener. Is this by design? > > > > I do plan to eventually look at whether I need to add my own > implementation or extension to the GenericHelixController but for now want > to get a quick prototype working, so is there a default implementation for > the InstanceConfigChangeListener I can use? > > > > Thanks, > > > > Sandeep >
