It's no longer dead AFAICT, so I doubt that I can be very precise here. When the enRoute stuff first came up, several more or less front pages of osgi.org stopped displaying what they used to display, and displayed information about enRoute instead. I deleted my bookmarks, swore a bit, and moved on. As of today, the osgi.org front page is (back to?) displaying a front page, and searching in Google for 'ConfigurationListener' gets a hit for the 4.2 javadoc and no hit for the spec PDF, which is better than nothing.
On Sat, Oct 8, 2016 at 9:48 AM, Peter Kriens <[email protected]> wrote: > What URL went dead? > > > On Fri, Oct 7, 2016 at 11:46 PM, Benson Margulies <[email protected]> > wrote: >> >> On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett <[email protected]> >> wrote: >> > >> > On 7 Oct 2016, at 22:33, Benson Margulies <[email protected]> wrote: >> > >> > On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett <[email protected]> >> > wrote: >> > >> > >> > On 7 Oct 2016, at 20:56, Benson Margulies <[email protected]> wrote: >> > >> > On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts <[email protected]> >> > 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 >> > [email protected] >> > https://mail.osgi.org/mailman/listinfo/osgi-dev >> > >> > >> > -- >> > Ferry Huberts >> > _______________________________________________ >> > OSGi Developer Mail List >> > [email protected] >> > https://mail.osgi.org/mailman/listinfo/osgi-dev >> > >> > _______________________________________________ >> > OSGi Developer Mail List >> > [email protected] >> > https://mail.osgi.org/mailman/listinfo/osgi-dev >> > >> > >> > >> > _______________________________________________ >> > OSGi Developer Mail List >> > [email protected] >> > https://mail.osgi.org/mailman/listinfo/osgi-dev >> > >> > _______________________________________________ >> > OSGi Developer Mail List >> > [email protected] >> > https://mail.osgi.org/mailman/listinfo/osgi-dev >> > >> > >> > >> > _______________________________________________ >> > OSGi Developer Mail List >> > [email protected] >> > https://mail.osgi.org/mailman/listinfo/osgi-dev >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
