If you've bothered to set the service ranking, then in theory it matters which one you get :-)
I like the default of preferring greedy in order to get reproducible results. Configurable choices would be ok for experts :-) David Jencks > On Sep 25, 2018, at 11:14 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > > As a general remark: > > I guess all current checks in that plugin are debatable. It currently > contains checks that we found useful. And I think we'll make them > configurable in a future version of the plugin. > > For this specific check, it's there to ensure a reproducible system > regardless of in which order bundles and services are started. Greedy > for single cardinality only matters if you have more than one service > registered for that reference. With greedy you always get the same (with > the highest service ranking). Without greedy you get one of them and > that can vary over time. Now in theory it shouldn't matter which one you > get, in practice it often does. > > Regards > > Carsten > > > David Jencks wrote >> I’m not quite sure exactly what you are asking, and I don’t know what policy >> preference this plugin thinks is a good idea but... >> If a static reference goes away, of course the component instance will get >> deactivated, and if there’s another suitable service available a new >> instance will get activated. This happens with both static and greedy >> policies. With a greedy static reference, these will also trigger instance >> cycling: >> - single cardinality: a better match (service ranking) appearing. >> - multiple cardinality: more matches appearing. >> >> Unless you’ve set the minimum cardinality using config admin to the actual >> number of services, you probably want the greedy behavior for multiple >> cardinality references. The situation for single cardinality is more >> debatable. >> >> David Jencks >> >> >> Sent from my iPhone >> >>> On Sep 25, 2018, at 3:51 PM, Mark Derricutt <mark.derric...@smxemail.com> >>> wrote: >>> >>> Hey all, >>> >>> A question on checkGreedyReferences() in the new osgicheck-maven-plugin, we >>> got a lot of warnings about our static @Reference's needing to be greedy. >>> >>> From the ReferecePolicy.STATIC java doc: >>> >>> If a target service is available to replace the bound service which became >>> unavailable, the component configuration must be reactivated and bound to >>> the replacement service. >>> >>> Would this imply that regardless of the RELUCTANT/GREEDY setting, for a >>> static @Reference I should see the new/updated service - and if so, should >>> the warning only trigger for non static references? >>> >>> Mark >>> >>> "The ease with which a change can be implemented has no relevance at all to >>> whether it is the right change for the (Java) Platform for all time." — >>> Mark Reinhold. >>> >>> Mark Derricutt | Senior Developer >>> Phone: +64 9 302 0515 Fax: +64 9 302 0518 >>> Mobile: +64 21 562 533 Freephone: 0800 SMX SMX (769 769) >>> Twitter: @talios >>> SMX Limited: Level 10, 19 Victoria Street West, Auckland, New Zealand >>> Web: http://smxemail.com >>> >> > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org <mailto:cziege...@apache.org>
