@Reference multi binding & dynamics

[Ferry Huberts]

Hi,

Cross-posting because I don't know if the situation/problem below is by
design, a bug in bnd, or a bug in SCR


I have a R6 component that does
@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)

This appears to not bind new matching services, because the policy
appears to be STATIC by default.

I did expect the ReferenceCardinality.AT_LEAST_ONE to imply
ReferencePolicy.DYNAMIC, just like the bnd annotations did.

Changing it to
@Reference(policy = ReferencePolicy.DYNAMIC, cardinality =
ReferenceCardinality.AT_LEAST_ONE)

appears to make it work like I expected.


Is this by design?

Coming from bnd annotations this - to me - seems like another (breaking)
subtlety.

--
Ferry Huberts

[Tim Ward]

I am relatively certain that this is the specified behaviour, and that it is consistent with the bnd annotation properties that it replaces

Specifying AT_LEAST_ONE is the same as saying multiple=true, optional=false on the bnd annotation, not using bnd's '+' shortcut.

The standard annotations map one annotation property to one XML attribute, which bnd did not (optional and multiple both being cardinality restrictions). Bnd later added shortcuts for some common DS cases, which is the source of the behaviour difference.

I hope this helps,

Tim

Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "bndtools-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Neil Bartlett]

> On 7 Oct 2015, at 13:56, Ferry Huberts <mail...@hupie.com> wrote:
>
> Hi,
>
> Cross-posting because I don't know if the situation/problem below is by design, a bug in bnd, or a bug in SCR
>
>
> I have a R6 component that does
> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
>
> This appears to not bind new matching services, because the policy appears to be STATIC by default.

Yes, static policy has always been the default in DS. You can see this right back in the very first DS specification found in OSGi Compendium R4.0, section 112.3.3: "The static policy is the most simple policy and is the default policy”. Also section 112.10 that gives the XML schema, where the reference element has the policy attribute defined as:

<attribute name="policy" type="scr:Tpolicy" default="static" use="optional"/>

>
> I did expect the ReferenceCardinality.AT_LEAST_ONE to imply ReferencePolicy.DYNAMIC, just like the bnd annotations did.

Nope. These are new annotations in a new namespace. There is no reason to expect them to have the same behaviour as the bnd annotations.

>
> Changing it to
> @Reference(policy = ReferencePolicy.DYNAMIC, cardinality = ReferenceCardinality.AT_LEAST_ONE)
>
> appears to make it work like I expected.
>
>
> Is this by design?
>
> Coming from bnd annotations this - to me - seems like another (breaking) subtlety.

It’s a subtlety perhaps because the standard annotations are just a direct, literal transformation to the XML, whereas the bnd ones tried to be “smart”. Yes, this is by design.

It’s certainly not breaking because, again, these are new annotations and there is no reason to expect them to do the same thing…

[Ferry Huberts]

On 07/10/15 18:01, Neil Bartlett wrote:
>> On 7 Oct 2015, at 13:56, Ferry Huberts <mail...@hupie.com> wrote:
>>
>> Hi,
>>
>> Cross-posting because I don't know if the situation/problem below is by design, a bug in bnd, or a bug in SCR
>>
>>
>> I have a R6 component that does
>> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
>>
>> This appears to not bind new matching services, because the policy appears to be STATIC by default.
> Yes, static policy has always been the default in DS. You can see this right back in the very first DS specification found in OSGi Compendium R4.0, section 112.3.3: "The static policy is the most simple policy and is the default policy”. Also section 112.10 that gives the XML schema, where the reference element has the policy attribute defined as:
>
> <attribute name="policy" type="scr:Tpolicy" default="static" use="optional"/>
>
>
>> I did expect the ReferenceCardinality.AT_LEAST_ONE to imply ReferencePolicy.DYNAMIC, just like the bnd annotations did.
> Nope. These are new annotations in a new namespace. There is no reason to expect them to have the same behaviour as the bnd annotations.

However, I challenge you to give me _one_ use-case where
ReferencePolicy.STATIC && ReferencePolicy.(MULTIPLE|AT_LEAST_ONE) makes
sense...

That combination _creates_ a timing dependency, services might or might
not be bound, depending on startup order.

A warning in bndtools like 'you probably meant to use
ReferencePolicy.DYNAMIC' when havingReferencePolicy.MULTIPLE or
ReferencePolicy.AT_LEAST_ONE would be nice IMHO

>
>> Changing it to
>> @Reference(policy = ReferencePolicy.DYNAMIC, cardinality = ReferenceCardinality.AT_LEAST_ONE)
>>
>> appears to make it work like I expected.
>>
>>
>> Is this by design?
>>
>> Coming from bnd annotations this - to me - seems like another (breaking) subtlety.
> It’s a subtlety perhaps because the standard annotations are just a direct, literal transformation to the XML, whereas the bnd ones tried to be “smart”. Yes, this is by design.
>
> It’s certainly not breaking because, again, these are new annotations and there is no reason to expect them to do the same thing…
>
>
>> --
>> Ferry Huberts
>>
>> --
>> You received this message because you are subscribed to the Google Groups "bndtools-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>

> --
> Ferry Huberts

[Ferry Huberts]

copy/paste error...

On 07/10/15 18:01, Neil Bartlett wrote:

>> On 7 Oct 2015, at 13:56, Ferry Huberts <mail...@hupie.com> wrote:
>>
>> Hi,
>>
>> Cross-posting because I don't know if the situation/problem below is by design, a bug in bnd, or a bug in SCR
>>
>>
>> I have a R6 component that does
>> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
>>
>> This appears to not bind new matching services, because the policy appears to be STATIC by default.
> Yes, static policy has always been the default in DS. You can see this right back in the very first DS specification found in OSGi Compendium R4.0, section 112.3.3: "The static policy is the most simple policy and is the default policy”. Also section 112.10 that gives the XML schema, where the reference element has the policy attribute defined as:
>
> <attribute name="policy" type="scr:Tpolicy" default="static" use="optional"/>
>
>
>> I did expect the ReferenceCardinality.AT_LEAST_ONE to imply ReferencePolicy.DYNAMIC, just like the bnd annotations did.
> Nope. These are new annotations in a new namespace. There is no reason to expect them to have the same behaviour as the bnd annotations.

However, I challenge you to give me _one_ use-case where

ReferencePolicy.STATIC && ReferenceCardinality.(MULTIPLE|AT_LEAST_ONE)

makes sense...

That combination _creates_ a timing dependency, services might or might
not be bound, depending on startup order.

A warning in bndtools like 'you probably meant to use

ReferencePolicy.DYNAMIC' when having ReferenceCardinality.MULTIPLE or
ReferenceCardinality.AT_LEAST_ONE would be nice IMHO

>
>> Changing it to
>> @Reference(policy = ReferencePolicy.DYNAMIC, cardinality = ReferenceCardinality.AT_LEAST_ONE)
>>
>> appears to make it work like I expected.
>>
>>
>> Is this by design?
>>
>> Coming from bnd annotations this - to me - seems like another (breaking) subtlety.
> It’s a subtlety perhaps because the standard annotations are just a direct, literal transformation to the XML, whereas the bnd ones tried to be “smart”. Yes, this is by design.
>
> It’s certainly not breaking because, again, these are new annotations and there is no reason to expect them to do the same thing…
>
>
>> --
>> Ferry Huberts
>>
>> --
>> You received this message because you are subscribed to the Google Groups "bndtools-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>

> --
> Ferry Huberts

---------------------------------------------------------------------
To unsubscribe, e-mail: users-un...@felix.apache.org
For additional commands, e-mail: users...@felix.apache.org


--
Ferry Huberts

[Tim Ward]

Sent from my iPhone

> On 7 Oct 2015, at 18:13, Ferry Huberts <mail...@hupie.com> wrote:
>
>
>
> On 07/10/15 18:01, Neil Bartlett wrote:
>>> On 7 Oct 2015, at 13:56, Ferry Huberts <mail...@hupie.com> wrote:
>>>
>>> Hi,
>>>
>>> Cross-posting because I don't know if the situation/problem below is by design, a bug in bnd, or a bug in SCR
>>>
>>>
>>> I have a R6 component that does
>>> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
>>>
>>> This appears to not bind new matching services, because the policy appears to be STATIC by default.
>> Yes, static policy has always been the default in DS. You can see this right back in the very first DS specification found in OSGi Compendium R4.0, section 112.3.3: "The static policy is the most simple policy and is the default policy”. Also section 112.10 that gives the XML schema, where the reference element has the policy attribute defined as:
>>
>> <attribute name="policy" type="scr:Tpolicy" default="static" use="optional"/>
>>
>>
>>> I did expect the ReferenceCardinality.AT_LEAST_ONE to imply ReferencePolicy.DYNAMIC, just like the bnd annotations did.
>> Nope. These are new annotations in a new namespace. There is no reason to expect them to have the same behaviour as the bnd annotations.
>
> However, I challenge you to give me _one_ use-case where ReferencePolicy.STATIC && ReferencePolicy.(MULTIPLE|AT_LEAST_ONE) makes sense...
> That combination _creates_ a timing dependency, services might or might not be bound, depending on startup order.
>

You don't need to be dynamic if your reference is greedy. That will eagerly pick up new services as they arrive too, just restarting the component when it changes.

[David Jencks]

Another use case is where you have set the <ref-name>.cardinality.minimum property to the expected number of actual services.

david jencks

[Ferry Huberts]

On 07/10/15 18:22, David Jencks wrote:

Another use case is where you have set the <ref-name>.cardinality.minimum property to the expected number of actual services.

I can see Tim's case, but this one is rather icky/hackish to me. It implies knowledge of how the component is going to be deployed.

Anyway, it's all cleared up now as being by design and I fixed up my code, so thanks to all.

[Neil Bartlett]

On 7 Oct 2015, at 17:36, Ferry Huberts <mail...@hupie.com> wrote:

On 07/10/15 18:22, David Jencks wrote:

Another use case is where you have set the <ref-name>.cardinality.minimum property to the expected number of actual services.

I can see Tim's case, but this one is rather icky/hackish to me. It implies knowledge of how the component is going to be deployed.

Anyway, it's all cleared up now as being by design and I fixed up my code, so thanks to all.

I do think there’s a case for bnd to give warnings for some combinations, it’s just not as straightforward as “multiple + static = bad”.

Please raise a feature request in the issue tracker.

Cheers,

Neil