On Mon, Feb 18, 2019 at 9:39 AM Thomas Driessen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:
> Hi Tim,
>
> as always thanks for your super detailed answer!
>
> Just two more questions on this topic:
>
> 1) Out of curiosity: do you know why the decision was made to make the
> default for @Reference List<ITest> static, reluctant? For 0/1..1 this makes
> sense to me, but for me an expected default behavior for 0/1..n references
> would have been dynamic, greedy, so that I end up with some services
> isntead of probably none.
>
The default is reluctant because "greedy" did not exist until DS 1.2. If
the default had been made greedy at that time, components coded before DS
1.2 would have seen a substantial change in behaviour that could be
considered non-backwards-compatible.
Static has *always* been the default over dynamic, because dynamic forces
the developer to understand thread safety and to code the component much
more cautiously. Static is simple and safe.
>
> 2) The observed Exception for optional/dynamic/reluctant: Is it intended?
> I tried to switch to bnd 4.2.0 to see if this exxception occurs there too,
> but was unable to do so. When I change the version number of bnd to 4.2.0
> in the standard enRoute setup, then some of the bnd-plugins can not be
> found by maven.
>
Probably not expected, this smells like a bug.
>
> Kind regards,
> Thomas
>
> ------ Originalnachricht ------
> Von: "Tim Ward" <tim.w...@paremus.com>
> An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer
> Mail List" <osgi-dev@mail.osgi.org>
> Cc: "Raymond Auge" <raymond.a...@liferay.com>
> Gesendet: 18.02.2019 10:15:54
> Betreff: Re: [osgi-dev] Clarification on reference behavior regarding
> field injection
>
> 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>
> An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer
> Mail List" <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> 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
>> 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
> 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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
