> On 7 Oct 2016, at 22:33, Benson Margulies <bimargul...@gmail.com> wrote: > > On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett <njbartl...@gmail.com > <mailto:njbartl...@gmail.com>> wrote: >> >> 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> 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”. > > I will do a better job of reading the specs when they are plain HTML > files, searched by google, and not fenced with a mile legal verbiage.
Please don’t misunderstand… when I give a reference to the spec it’s to back up what I’m saying so that you know it’s true, and to give you the opportunity to dig deeper. It is certainly NOT an accusation that you are being lazy for not already having found this information yourself. I would also like the specs to be more searchable. The PDFs look beautiful but that’s not so important unless they are in book form, and who wants to carry around a 1246 pages of Compendium? Neil > > >> >> 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 >> 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 <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
