What URL went dead?
On Fri, Oct 7, 2016 at 11:46 PM, Benson Margulies <bimargul...@gmail.com> wrote: > On Fri, Oct 7, 2016 at 5: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. > > OK, sorry about the snark. I have a certain amount of pent-up > frustration, especially after a bunch of URLs went dead when the > enRoute info went up. Thanks as always for the help. > > > > > > 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 >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
