And on the way we may need to extend ClusterStateStore to be able to store more data.
Also see: https://issues.apache.org/jira/browse/WHIRR-424 -- Andrei Savu 2011/12/14 Andrei Savu <[email protected]> > Just the summarise the discussion from IRC with Ioannis: > > Because we are only using specific versions & clients durring integration > testing and we want to keep Whirr as service version agnostic as possible > (e.g. I think we can now deploy both ZooKeeper 3.3.x and 3.4.x because the > config files are the same even if the client library is different) the only > way we can do this is by publishing a bunch of key - value pairs that > contain connection details and version numbers using an OSGi aware > ClusterStore implementation. > > > On Wed, Dec 14, 2011 at 3:32 PM, Ioannis Canellos <[email protected]>wrote: > >> Hi Andrei, >> >> From a quick glance I gave to the ClusterServiceStore I think that it is >> mostly used to store metadata that are more linked to the nodes, rather >> than the service itself. >> We could have an osgi specific implementation that would store this >> information in the configuration admin (an osgi service which provides >> access, listeners etc to the configuration data). >> However, I am not sure if it can be used in order to add whirr services >> to the OSGi service registry. >> >> -- >> Ioannis Canellos >> >> On 14 Δεκ 2011, at 2:49 μ.μ., Andrei Savu wrote: >> >> > Ioannis, >> > >> > I know you've mentioned something about registering services started by >> > Whirr in OSGi on the IRC. Do you think we can accomplish this by a >> having a >> > new implementation of ClusterStateStore? >> > >> > This could make Whirr really useful inside OSGi environments. >> > >> > -- Andrei Savu >> >> >
