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 <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

Reply via email to