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 > >
