Am 23.02.15 um 09:46 schrieb David Bosschaert:
> Well there are other OSGi mechanisms to declare depends-on
> relationships, such as import/export packages, require-bundle (which
> nobody should use) and generic capabilities and requirements
> (Provide-Capability / Require-Capability). However, what we want here
> as far as I understand is a model where a DS component only exist if
> it's its mapping is available. For this purpose service dependencies
> are the only option AFAICS.
> 

I think in this case we need a runtime or dynamic dependency while
packages depedencies and capabilities are not really dynamic and are
only useful at wiring time

Carsten

> My 2c,
> 
> David
> 
> On 23 February 2015 at 15:33, Tommaso Teofili <[email protected]> 
> wrote:
>> 2015-02-21 8:55 GMT+01:00 Carsten Ziegeler <[email protected]>:
>>
>>> Am 20.02.15 um 18:53 schrieb Marius Petria:
>>>> Hi,
>>>>
>>>> I discovered an issue related to service users. Due to the indeterminism
>>>> of OSGI a consumer of ServiceUserMapper cannot be sure that
>>>> getServiceUserID will find a registered mapping even if that mapping has
>>>> been configured. For example if a component starts roughly at the same
>>>> time as the mapping is installed it can happen that the calls the
>>>> component makes to loginService to fail. More concretely that can happen
>>>> for example if one needs a session in an activate method to register jcr
>>>> event listener, or to read some configuration properties from the
>>>> repository.
>>>>
>>>> In order to make this behavior more predictable I created an issue [1]
>>>> proposing to always register an osgi service (I called it
>>>> ServiceUserMapping) right after a mapping is installed, such that
>>> consumer
>>>> components can reference it and wait for the mapping to be available. I
>>>> also worked out an implementation in [2].
>>>>
>>>> First, I would like to ask you if you think the problem is valid and if
>>>> the approach is correct?
>>>> Second, it will be really helpful if you can also comment on the issue
>>>> around the provided implementation.
>>>>
>>> In OSGi you should declare your dependencies, which means for components,
>>> the only option you have is requiring services. Therefore translating
>>> the above problem into service dependencies is imho the right way.
>>>
>>
>> it looks like using a service is the right way to address this need
>> because, as Carsten said and as far as I know, it's the only OSGi mechanism
>> for declaring a "depends-on" relationship.
>>
>> So I'm +1 for the proposed approach.
>>
>> Regards,
>> Tommaso
>>
>>
>>>
>>> Carsten
>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> [email protected]
>>>
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
[email protected]

Reply via email to