Hi Neil,
thanks for this small history lesson on OSGi. You live, you learn. The
why is in most cases so much more interesting than the what :)
I will open an issue on Github then for bnd.
Kind regards,
Thomas
------ Originalnachricht ------
Von: "Neil Bartlett" <njbartl...@gmail.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer
Mail List" <osgi-dev@mail.osgi.org>
Cc: "Tim Ward" <tim.w...@paremus.com>
Gesendet: 18.02.2019 10:44:14
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding
field injection
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 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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
