On Thu, Dec 20, 2018 at 10:18 AM Jasper Simon <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 > For additional commands, e-mail: users-h...@felix.apache.org > >
