I hesitate to prolong this thread, but FWIW: Google can index PDFs just fine, what their seachbot doesn't do is to click through "I agree to ..." checkboxes.
Whether the "front page" of a web site should always display the same information is another question. Most don't. > These sides are -completely- disconnected and run by very different > webmasters. > > Kind regards, > > Peter Kriens > >> On 11 okt. 2016, at 16:28, Benson Margulies <[email protected]> >> wrote: >> >> 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 > > _______________________________________________ > 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
