You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Mark Derricutt <ma...@smxemail.com> on 2018/09/25 22:51:49 UTC
osgicheck-maven-plugin and checkGreedyReferences()
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
Re: osgicheck-maven-plugin and checkGreedyReferences()
Posted by Raymond Auge <ra...@liferay.com>.
I also agree with GREEDY as a general rule for any STATIC unary references.
On top of the reasons proposed by Carsten and David, what a developer often
overlooks is the "plugability" of the system.
Whenever you use OSGi services, the natural assumption is that the "best"
service will be used based on service ranking.
During deployment (and generally long after development) the first thought
is simply to change the default implementation with a service of higher
ranking. However, when code uses the default @Reference this becomes only
possible by applying a specific target filter for the reference.
You might need to replace only one service, but you have 20 @References
spread through the application requiring 20 unique configurations targeting
the custom implementation.
Had all the references been GREEDY, the system would have worked as
expected from the start.
NOTE that the OSGi EGs (Expert Groups) have expressed regret at not having
made @References GREEDY to begin with. To that end when developing the CDI
integration spec, OSGi CDI's @Reference IS GREEDY by default.
Sincerely,
- Ray
On Wed, Sep 26, 2018 at 2:40 AM David Jencks <da...@gmail.com>
wrote:
> 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 <cz...@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.derricutt@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
> > cziegeler@apache.org <ma...@apache.org>
>
--
*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)
Re: osgicheck-maven-plugin and checkGreedyReferences()
Posted by David Jencks <da...@gmail.com>.
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 <cz...@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 <ma...@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
> cziegeler@apache.org <ma...@apache.org>
Re: osgicheck-maven-plugin and checkGreedyReferences()
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <ma...@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
cziegeler@apache.org
Re: osgicheck-maven-plugin and checkGreedyReferences()
Posted by David Jencks <da...@gmail.com>.
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 <ma...@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
>