Hi Thomas, Just to clarify, the behaviour that you see with static reluctant services will always look “odd” for cardinalities other than mandatory, and what you’ve recorded is 100% correct behaviour.
Static references force the component to be re-created if the value of the reference changes Reluctant references avoid rebinding the service unless it is required Therefore: An optional reference bound to nothing will never bind to anything again (unless the component is re-created for another reason) because having zero references is valid and you are reluctant to re-create the component instance An optional reference bound to a service will not change until that service is unregistered (ignoring all new services), at which point it will either: Pick up the highest ranked of any matching registered services Bind to nothing if no matching services are available A multiple reference bound to nothing will behave exactly like an optional component A multiple reference bound to one or more services will not change until any of the bound services are unregistered (ignoring all new services), at which point it will either: Pick up all the available registered services Bind to nothing if no matching services are available An “at least one" reference bound to one or more services will not change until any of the bound services are unregistered (ignoring all new services), at which point it will either: Pick up all the available registered services Make the component unsatisfied The end result of this is that references that can accept zero will tend to zero over time, and then tend to stay with zero bound references. At least one references will tend to a small number of “stable” services with new services ignored. In general references of these types should be dynamic or greedy (or both). Best Regards, Tim > On 18 Feb 2019, at 09:38, Thomas Driessen via osgi-dev > <osgi-dev@mail.osgi.org> wrote: > > Oh Sorry :/ > > Those combinations with cardinalities optional/mandatory have been assigned > to ITest, those with multiple/at_least_one have been assigned to List<ITest>. > > I didn't think it makes sense to assign them vice versa, e.g., ITest with > multiple or List<ITest> with mandatory? Or am I wrong? If so, in what case > would you use such a combination? > > Kind regards, > Thomas > > ------ Originalnachricht ------ > Von: "Raymond Auge" <raymond.a...@liferay.com > <mailto:raymond.a...@liferay.com>> > An: "Thomas Driessen" <thomas.driessen...@gmail.com > <mailto:thomas.driessen...@gmail.com>>; "OSGi Developer Mail List" > <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> > Gesendet: 16.02.2019 17:42:19 > Betreff: Re: [osgi-dev] Clarification on reference behavior regarding field > injection > >> You're chart doesn't appear to list _which_ field (Reference) was associated >> with any given line (collection vs. scalar). It makes a difference. >> >> - Ray >> >> On Sat, Feb 16, 2019 at 9:15 AM Thomas Driessen via osgi-dev >> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote: >> Hi, >> >> I'm trying to get an overview over the effects of different combinations of >> cardinality, policy and policyOption within a @Reference annotation for a >> field. >> >> My Example looks like this: >> >> @Component >> public class MyComp{ >> @Reference(...) >> ITest myTest; >> >> @Reference(...) >> List<ITest> myTests; >> } >> >> and the observed behavior for this setup with different combinations of the >> above named properties is: >> <image.png> >> >> I'm especially interested in the yellow marked cases: Is this an intended >> behavior? >> >> Kind regards, >> Thomas >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >> >> -- >> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) >> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance) > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <https://mail.osgi.org/mailman/listinfo/osgi-dev>
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
