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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
