On Wed, Oct 12, 2016 at 3:36 PM, <chris.g...@kiffer.be> wrote: > 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.
The point was, that at the time there was no navigation at all to reach the javadoc or pdfs. Believe me or not. > >> These sides are -completely- disconnected and run by very different >> webmasters. >> >> Kind regards, >> >> Peter Kriens >> >>> On 11 okt. 2016, at 16:28, Benson Margulies <bimargul...@gmail.com> >>> 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 <peter.kri...@aqute.biz> >>> wrote: >>>> 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 >>> _______________________________________________ >>> 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
