> On 7 Oct 2015, at 17:36, Ferry Huberts <maili...@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 > >> david jencks >> >>> On Oct 7, 2015, at 12:17 PM, Tim Ward < >>> <mailto:tim.w...@paremus.com>tim.w...@paremus.com >>> <mailto:tim.w...@paremus.com>> wrote: >>> >>> >>> >>> Sent from my iPhone >>> >>>> On 7 Oct 2015, at 18:13, Ferry Huberts <maili...@hupie.com >>>> <mailto:maili...@hupie.com>> wrote: >>>> >>>> >>>> >>>> On 07/10/15 18:01, Neil Bartlett wrote: >>>>>> On 7 Oct 2015, at 13:56, Ferry Huberts <maili...@hupie.com >>>>>> <mailto:maili...@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. >>> >>> >>>> 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 >>>>>> <mailto:bndtools-users+unsubscr...@googlegroups.com>bndtools-users+unsubscr...@googlegroups.com >>>>>> <mailto:bndtools-users+unsubscr...@googlegroups.com>. >>>>>> For more options, visit https://groups.google.com/d/optout >>>>>> <https://groups.google.com/d/optout>. >>>>> >>>>> -- >>>>> 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-users+unsubscr...@googlegroups.com >>>> <mailto:bndtools-users+unsubscr...@googlegroups.com>. >>>> For more options, visit https://groups.google.com/d/optout >>>> <https://groups.google.com/d/optout>. >>> >>> -- >>> 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 >>> <mailto:bndtools-users+unsubscr...@googlegroups.com>bndtools-users+unsubscr...@googlegroups.com >>> <mailto:bndtools-users+unsubscr...@googlegroups.com>. >>> For more options, visit >>> <https://groups.google.com/d/optout>https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> -- >> 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-users+unsubscr...@googlegroups.com >> <mailto:bndtools-users+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> -- >> 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-users+unsubscr...@googlegroups.com > <mailto:bndtools-users+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>.
