Probably the main reason (I wasn't involved in the EG discussions personally) is that reluctant was the *only* option before DS 1.2 (part of OSGi Release 5). If the greedy option had been introduced and used as the default, it would have broken backwards compatibility.
Even before DS 1.2 and/or when using the reluctant option, a component can still obtain the highest rank service simply by binding dynamically with multiple cardinality, i.e. 0..n or 1..n. You just gather all the references into a SortedSet. Neil On Thu, Dec 20, 2018 at 1:02 PM Jasper Simon <jasperxsi...@gmail.com> wrote: > Hi Neil, > > I get what you’re saying, and indeed we’re building a workaround to > disable the specific component to force re-binding. > It does make me wonder why the default policy option is reluctant, not > greedy? Are there some specific reasons to do it this way? This default > seems to defeat the purpose of service rankings in some way. > > Kind regards, > Jasper > > > On 20 Dec 2018, at 11:42, Neil Bartlett <njbartl...@gmail.com> wrote: > > > > On Thu, Dec 20, 2018 at 10:18 AM Jasper Simon <jasperxsi...@gmail.com > <mailto:jasperxsi...@gmail.com>> > > wrote: > > > >> Hi Neil, > >> > >> Please excuse my confusing terminology, and thanks for the explanation. > >> I’ll try to be more clear. > >> > > > > No problem. > > > > > >> > >> Component A and C provide the same service. B binds to that service. > >> Because B and C are in the same bundle and that bundle starts before the > >> bundle containing A, on startup B will bind to the service provided by > C. > >> > > > > I see, this is much clearer now. Thank you. > > > > > >> B and C are in an external library, so we do not maintain that code. > >> > >> How can I make B re-bind the reference, without changing the reference > >> policy option? > > > > > > As I explained, you can't because this is the very definition of the > > reluctant policy option. > > > > Some aspects of a service reference can be changed through configuration > > (i.e. using Config Admin). As of OSGi R7, these are limited to the target > > filter and the minimum cardinality; the policy option cannot be modified > by > > config. > > > > However this suggests a hacky workaround perhaps. You could use Config > > Admin to modify the target filter property of the reference in component > B > > so that the filter does not match the service from C. For example you > could > > use the service.bundleid property like this: `(!(service.bundleid=c))` > > where `c` is the numeric bundle ID of the bundle containing components B > > and C. You would have to generate this string programmatically. Bear in > > mind that the B component would come up initially bound to the service > from > > C before your configuration can take effect. > > > > It works because you are now making it *impossible* for B to remain bound > > to the service from C, which is the only time a reluctant reference will > > re-bind. But it is not very satisfactory and I would strongly recommend > > trying to adjust the original bundle instead! > > > > Neil > > > > > >> > >> > >> Kind regards, > >> Jasper > >> > >> > >>> On 20 Dec 2018, at 10:32, Neil Bartlett <njbartl...@gmail.com> wrote: > >>> > >>> Hello Jasper, > >>> > >>> Your terminology is confused which makes this very hard to follow. > >>> Hopefully I have interpreted correctly, see my actual answer below. > >>> > >>> On Thu, Dec 20, 2018 at 9:12 AM Jasper Simon <jasperxsi...@gmail.com> > >> wrote: > >>> > >>>> Hi, > >>>> > >>>> I’ve been trying to get my osgi component A bound to another component > >> B. > >>> > >>> > >>> Components do not bind to components, they bind to services. Those > >> services > >>> might be provided by components, or they might not. > >>> > >>> > >>>> B already has a component C of that service bound to it, with default > >>>> service ranking 0. > >>>> > >>> > >>> So... component A binds to a service provided by component B? And B > binds > >>> to a service provided by the component C. Effectively there is a > chain, A > >>> -> B -> C? Is that correct? If not, please try to explain more clearly. > >>> > >>> > >>>> For this reference in A, the policy option is reluctant. B and C are > in > >>>> same bundle, A is in another bundle with a higher start level. This > >> means > >>>> that when the bundle with A is started, B has already bound C and will > >> not > >>>> bind A, even though it has a higher service ranking. > >>> > >>> > >>> If a component is bound to a service using a reluctant reference, then > >> that > >>> reference will NOT be re-bound when a higher-ranked service comes > along. > >>> This is part of the definition of the reluctant policy option, see OSGi > >>> Compendium Release 6, section 112.3.7. > >>> > >>> > >>>> In our case, it’s not possible to change the bundles' start order. > >>> > >>> > >>> That's fine, the functionality of your system should not depend on > >>> something so unstable as bundle start order. > >>> > >>> Making the reference policy option greedy is also not possible, as > bundle > >>>> B/C is imported as a dependency. > >>>> > >>> > >>> This statement does not explain why you cannot make the reference > policy > >>> greedy. Reference policy has got absolutely nothing to do with bundle > >>> dependencies. > >>> > >>> Neil > >>> > >>> > >>>> > >>>> Any thoughts? > >>>> > >>>> Kind regards, > >>>> Jasper > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org <mailto: > users-unsubscr...@felix.apache.org> > >> For additional commands, e-mail: users-h...@felix.apache.org <mailto: > users-h...@felix.apache.org> >
