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.
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.
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 changesReluctant 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 instanceAn 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 servicesBind to nothing if no matching services are
availableA multiple reference bound to nothing will behave exactly like
an optional componentA 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 servicesBind to nothing if no matching
services are availableAn “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 servicesMake 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
