> 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.
That’s because and 4.2.0 isn’t released yet - you need to add a plugin repository containing 4.2.0-SNAPSHOT (which is also the version you should be using. If you look at the readme for the bnd repo on GitHub you can see the repo url is https://bndtools.jfrog.io/bndtools/libs-snapshot/ <https://bndtools.jfrog.io/bndtools/libs-snapshot/> Tim > On 18 Feb 2019, at 10:51, Thomas Driessen <thomas.driessen...@gmail.com> > wrote: > > 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 <mailto:njbartl...@gmail.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>> > Cc: "Tim Ward" <tim.w...@paremus.com <mailto: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 <mailto: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 <mailto:tim.w...@paremus.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>> >> Cc: "Raymond Auge" <raymond.a...@liferay.com >> <mailto: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 <mailto: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 <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
