Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Benson Margulies]

On Wed, Oct 12, 2016 at 3:36 PM,   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 
>>> 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 
>>> wrote:
 What URL went dead?


 On Fri, Oct 7, 2016 at 11:46 PM, Benson Margulies
 
 wrote:
>
> On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett 
> wrote:
>>
>> On 7 Oct 2016, at 22:33, Benson Margulies 
>> wrote:
>>
>> On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett 
>> wrote:
>>
>>
>> On 7 Oct 2016, at 20:56, Benson Margulies 
>> wrote:
>>
>> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts 
>> 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 

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[chris . gray]

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 
>> 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 
>> wrote:
>>> What URL went dead?
>>>
>>>
>>> On Fri, Oct 7, 2016 at 11:46 PM, Benson Margulies
>>> 
>>> wrote:

 On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett 
 wrote:
>
> On 7 Oct 2016, at 22:33, Benson Margulies 
> wrote:
>
> On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett 
> wrote:
>
>
> On 7 Oct 2016, at 20:56, Benson Margulies 
> wrote:
>
> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts 
> 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 

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Peter Kriens]

These sides are -completely- disconnected and run by very different webmasters.

Kind regards,

Peter Kriens

> On 11 okt. 2016, at 16:28, Benson Margulies  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  wrote:
>> What URL went dead?
>> 
>> 
>> On Fri, Oct 7, 2016 at 11:46 PM, Benson Margulies 
>> wrote:
>>> 
>>> On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett 
>>> wrote:
 
 On 7 Oct 2016, at 22:33, Benson Margulies  wrote:
 
 On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett 
 wrote:
 
 
 On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
 
 On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts 
 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: 

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Benson Margulies]

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  wrote:
> What URL went dead?
>
>
> On Fri, Oct 7, 2016 at 11:46 PM, Benson Margulies 
> wrote:
>>
>> On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett 
>> wrote:
>> >
>> > On 7 Oct 2016, at 22:33, Benson Margulies  wrote:
>> >
>> > On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett 
>> > wrote:
>> >
>> >
>> > On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
>> >
>> > On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts 
>> > 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="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

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Peter Kriens]

What URL went dead?


On Fri, Oct 7, 2016 at 11:46 PM, Benson Margulies 
wrote:

> On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett 
> wrote:
> >
> > On 7 Oct 2016, at 22:33, Benson Margulies  wrote:
> >
> > On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett 
> wrote:
> >
> >
> > On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
> >
> > On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts 
> 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="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
> > 

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Elliot Huntington]

Me. 

On Oct 7, 2016 3:41 PM, "Neil Bartlett"  wrote:

>
> On 7 Oct 2016, at 22:33, Benson Margulies  wrote:
>
> On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett 
> wrote:
>
>
> On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
>
> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts  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.
>
> 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="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
> 

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Benson Margulies]

On Fri, Oct 7, 2016 at 5:41 PM, Neil Bartlett  wrote:
>
> On 7 Oct 2016, at 22:33, Benson Margulies  wrote:
>
> On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett  wrote:
>
>
> On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
>
> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts  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="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

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Neil Bartlett]

> On 7 Oct 2016, at 22:33, Benson Margulies  wrote:
> 
> On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett  > wrote:
>> 
>> On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
>> 
>> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts  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.

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

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Benson Margulies]

On Fri, Oct 7, 2016 at 4:21 PM, Neil Bartlett  wrote:
>
> On 7 Oct 2016, at 20:56, Benson Margulies  wrote:
>
> On Fri, Oct 7, 2016 at 3:45 PM, Ferry Huberts  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.


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

Re: [osgi-dev] A middle ground between hard dependencies and purely dynamic dependencies (DS)

[Ferry Huberts]

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.

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