Hi Guys
I was trying to understand the approach.
What is the goal of building multiple version support for OSGi only?
Specifically I didn't understand:
>> 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.
I get this would be necessary if we would maintain service bundles
separate from the dependencies, (e.g. whirr-zookeeper.jar separate from
zookeeper.jar), or if we wanted to have multiple versions at the same time.
But wouldn't it be enough to just build a uber-bundle (using
felix-bundle-plugin), include all the specific dependencies in the bundle and
then make whirr-core in OSGi just use the version available? I mean the
interfaces between whirr-core and whirr-service* are already version agnostic.
I may be way off as there has been some time since I messed with OSGi,
so what do you think?
Cheers
-david
On Dec 14, 2011, at 8:41 AM, Andrei Savu wrote:
> 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
>>>
>>>
>>
