Right. If you used static+greedy then you would see the deactivate and activate methods called. This is because static would force DS to create a new component instance.
Neil On Tue, 10 Jul 2018 at 22:31, Alain Picard <pic...@castortech.com> wrote: > Neil, > > As you saw I was on the right track but what I failed to realize is that > this doesn't trigger a new call to the @Activate method. I changed the > reference to use a bind/unbind method pair and a sysout in there shows > exactly the pattern that you described. > > Thanks > Alain > > > On Tue, Jul 10, 2018 at 5:13 PM Neil Bartlett <njbartl...@gmail.com> > wrote: > >> Your reference to service ICoreUtils in Example is mandatory, static and >> reluctant. This means that whichever service it first binds to, it will >> hold for as long as possible. >> >> Since the lower ranked service is published by a bundle with a lower ID, >> it is probably published first. So that’s the one you will get. >> >> If you uncomment the dynamic+greedy setting in Example I expect you will >> see the component briefly bind to the lower ranked service and then re-bind >> to the higher ranked service. This is part of the definition of greedy. >> >> Neil >> >> On Tue, 10 Jul 2018 at 22:05, Alain Picard via osgi-dev < >> osgi-dev@mail.osgi.org> wrote: >> >>> As part of DS enabling a lot of our code, I am testing how to compose >>> services after finding out that reference annotations are not inherited. >>> But I am facing a much more basic issue dealing with service ranking. >>> >>> Made a trivial example of an interface with one method and 2 >>> implementation and with one having a higher service ranking. I always get >>> the same one to execute and not the one I expect (only get the other if I >>> comment the @Component reference on CoreUtils and then it refreshes with >>> ExtUtils. >>> >>> What is wrong with my approach. >>> [image: image.png] >>> >>> _______________________________________________ >>> 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
