Me. š On Oct 7, 2016 3:41 PM, "Neil Bartlett" <njbartl...@gmail.com> wrote:
> > 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> > 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 > 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 > 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
