> On 7 Oct 2016, at 20:56, Benson Margulies <bimargul...@gmail.com> wrote: > > On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts <maili...@hupie.com > <mailto:maili...@hupie.com>> wrote: >> >> >> On 07/10/16 21:04, Benson Margulies wrote: >>> >>> I am trying to express the following idea using DS: >>> >>> "If service X is provisioned in this container, do not activate me >>> until it is activated and injected into me. If service X is not >>> provisioned in this container, go ahead and activate me without it." >> >> >> how about making the dependency: static + greedy + optional. > > So, in practical terms, how greedy is 'greedy'? What's the behavior?
Greedy means that if a service becomes available after your component is activated, then it will *always* be supplied to your component, even if that forces a restart of the component due to the reference having static policy. (It’s worth contrasting this with its opposite, reluctant: if you have an optional, static, reluctant reference then your component will NOT be restarted in order to give it a service that arrives after it is activated. That is, the component will continue to be bound to nothing even when a valid candidate service is available. While this makes perfect sense if you take the time to think it through, OSGi newbies tend to find it counterintuitive). By the way, with a greedy reference, you will also get re-bound when a service comes along that has a higher ranking than the one you are currently bound to. Again, this happens even if it requires restarting the component due to a static reference policy. All this is in the R6 Compendium spec, Section 112.3.7 “Reference Policy Option”. Regards, Neil > >> >> that way your component will get started always, and restarted once X >> becomes available. >> >>> >>> I fully appreciate that this concept is not compatible with the >>> generally dynamic approach of OSGi in general, and declarative >>> services in particular. However, I can think of a variation like: >>> >>> "I am willing to wait N seconds for service X. If it isn't there by >>> then, activate me without it." >>> >>> I am taking a risk here -- it's always possible that some phenomenon >>> would result in a delay of longer than N. But in my case, the startup >>> properties of the containing application are such that this would be a >>> low risk. >>> >>> Another possible approach would be to focus on provide/require >>> capability. I don't know how I would get DS to pay attention, but it >>> seems as if there's not enough information: >>> >>> Provide-Capability: osgi.service;objectClass:List<String>="com.basiste >>> ch.rosette.osgi.RosetteBundleWarmup,com.basistech.rosette.osgi.Rosett >>> eComponentService" >>> >>> Note that any properties are not represented here. So if the >>> dependency is specific to some filter on properties, you can't use >>> this data. >>> >>> At the extreme, I could take very close control of start order, and >>> then go ahead and use optional references. That's a lot of start order >>> management. >>> >>> Finally? I could use configuration admin, by setting the reference >>> cardinality as part of provisioning. To do this cleanly, I think I'd >>> want some sort of management layer that generated these 'minimum >>> cardinality properties'; editing it in something like Karaf's cfg >>> files would be quite messy. >>> >>> Is there something I'm missing? >>> _______________________________________________ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >> -- >> Ferry Huberts >> _______________________________________________ >> 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 <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <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
