Re: How to 'let the dust settle' with DS?

[David Jencks]

> On Sep 7, 2015, at 8:07 PM, Benson Margulies  wrote:
> 
> The cardinality in the config admin does not seem to be sticking:
> 
> @Component(configurationPolicy = ConfigurationPolicy.REQUIRE,
> configurationPid = "com.basistech.ws.worker")
> 
> And:
> 
> @Reference(cardinality = ReferenceCardinality.MULTIPLE, policyOption =
> ReferencePolicyOption.GREEDY)
> public void setWorkerComponentService(WorkerComponentService
> workerComponentService) {
> 
> And in the relevant Karaf cfg file (com.basistech.ws.worker.cfg):
> 
> # This is a DS property. It tells DS that there is one component
> service that we are consuming.
> WorkerComponentService.cardinality.minimum=1
> 
> And the reference name in the DS metadata is WorkerComponentService.
> 
> but the component goes ahead and activates when it has none (due to
> leaving out the component); the activation throws an exception due to
> my own code complaining.
> 
> In spite of the exception thrown in the @Activate method, the
> component goes to REGISTERED, is there some particular exception that
> would prevent that?
> 
> I have it working (up to the point of fun with Json deserialization
> from CXF, which is also working mostly) by putting the component in
> place, but eventually I need the constraint to hold things up; and it
> would be nice to have a way for an exception in activation to stop the
> train.

The spec says:

• Once the component config- uration is deactivated or fails to 
activate due to an exception, SCR must unbind all the component's bound 
services and discard all references to the component instance associated with 
the activation. 

Note that this doesn’t disable the component or unregister any services it may 
be exposing, because the exception may be highly transient, and e.g. the next 
time someone gets the service all may work smoothly and activate succeed.

I don’t know what version of ds you are “stuck” with, at some point in the 
distant past I think that an exception on activation did something like 
disabling the component.  Due to all the cool new 1.3 features you should use 
the latest release 2.0 but the previous release may have also had the 
cardinality.minimum support… but don’t quote me :-)

thanks
david jencks


> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

This is easy to explain. The version of felix scr in karaf is too old.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

The cardinality in the config admin does not seem to be sticking:

@Component(configurationPolicy = ConfigurationPolicy.REQUIRE,
configurationPid = "com.basistech.ws.worker")

And:

@Reference(cardinality = ReferenceCardinality.MULTIPLE, policyOption =
ReferencePolicyOption.GREEDY)
public void setWorkerComponentService(WorkerComponentService
workerComponentService) {

And in the relevant Karaf cfg file (com.basistech.ws.worker.cfg):

# This is a DS property. It tells DS that there is one component
service that we are consuming.
WorkerComponentService.cardinality.minimum=1

And the reference name in the DS metadata is WorkerComponentService.

but the component goes ahead and activates when it has none (due to
leaving out the component); the activation throws an exception due to
my own code complaining.

In spite of the exception thrown in the @Activate method, the
component goes to REGISTERED, is there some particular exception that
would prevent that?

I have it working (up to the point of fun with Json deserialization
from CXF, which is also working mostly) by putting the component in
place, but eventually I need the constraint to hold things up; and it
would be nice to have a way for an exception in activation to stop the
train.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[David Leangen]

Hi Neil,

This got my attention:

> I have also said many times that people shouldn’t be using FileInstall in 
> production systems.

I must have missed the references you are referring to.

Can you elaborate, or perhaps point me to some references?

What _would_ be the “right" way to configure in a production system? (I must 
have been skipping out of school that day…)


Cheers,
=David


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[David Jencks]

> On Sep 7, 2015, at 5:06 PM, Benson Margulies  > wrote:
> 
> On Mon, Sep 7, 2015 at 4:07 PM, David Jencks
> mailto:david_jen...@yahoo.com.invalid>> 
> wrote:
>> So it looks like we lost most of the thread but to try to keep this from 
>> turning into more of a tangled ball of yarn the cat played with….
> 
> I'm sorry to be so poor at communicating.
>> 
>> 
>> 1) NO!:
>> 
>> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
>> public void setAllComponents(List allComponents) {
>> 
>> 
>> This might be a blueprint-ism but DOESNT WORK FOR DS
>> 
>> The event methods (bind/unbind/updated) don’t have to be called anything in 
>> particular but they need to take only ONE service/service 
>> reference/properties NOT a collection.
> 
> Oh, so they get called more than once? Yea, apparently I caught a
> social disease from Blueprint!
> 
> 
>> 
>> So
>> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
>> public void setWorkerComponentService(WorkerComponentService wcs) { …}
>> 
>> If you use DS 1.3 reference fields it can be a collection valued field.  
>> I’ve never used these except possibly in some tests.
>> 
>> 2) the minimum cardinality property has to be supplied from config admin, 
>> not component.xml.  So it is runtime modifiable.  I might have missed it but 
>> I didn’t see what your configuration was or how you were installing it.  You 
>> cannot set the minimum cardinality at compile time.
> 
> OK, I get it. That does simplify things.
> 
>> 
>> I think you are making life too hard for yourself.  From your description, 
>> when you set up the deployment of your stuff, you know exactly how many 
>> WorkerComponentService instances to expect, so you can put that value in the 
>> configuration.  Then DS will do the waiting for you, and your restful 
>> service component will get the references and activate once the appropriate 
>> number are ready.  If you expect to have more WorkerComponentServices 
>> registered, say 10, and want to restrict yourself to only using a particular 
>> 5 of them, you can, along with the cardinality to assure you get at least 5, 
>> use a target filter to find the exact 5 you want.  For instance, if the 
>> WorkerComponentServices have a “type” property that identifies which one 
>> they are, your filter in the configuration would look something like
>> 
>> WorkerComponentService.cardinality.minimum=5
>> WorkerComponentService.target=“(|(type=foo1)(type=foo2)(type=foo3)(type=foo4)(type=foo5))”
> 
> Do I really have to enumerate the types if I happen to have
> provisioned only the ones I want.

No, if you’re sure you know how many there will be you can just use the 
cardinality property.  I was showing the target filter approach in case you 
wanted a specific subset of the available services, and you want to be sure to 
get all the ones you want and exclude all the others.

thanks
david jencks


> 
>> 
>> Wiring up DS services is really powerful.  I haven’t figured out the exact 
>> computational strength available but to me it has the feel of logic 
>> programming.
>> 
>> thanks
>> david jencks
>> 
>> 
>> 
>>> On Sep 7, 2015, at 2:55 PM, Benson Margulies >> > wrote:
>>> 
>>> I think I now understand what I have failed to explain here (and I
>>> probably know why my service is acting like tantalus).
>>> 
>>> My plan is to create a series of docker containers. Call them
>>> 'workers'. Each worker publishes the same restful service; each one of
>>> them handles one or more 'tasks'. The worker accepts work via a single
>>> RESTful service, and dispatches the work to the tasks based on
>>> parameters in the requests to the service.
>>> 
>>> The set of tasks implemented on a particular worker is controlled the
>>> set of OSGi bundles I provision in it. I have a whole slew of them,
>>> each registers a 'RosetteComponentService'.
>>> 
>>> Each of these task bundles has, potentially, a bit of a startup delay
>>> as it gets organized.
>>> 
>>> I don't want to open the restful service until the components are all set 
>>> up.
>>> 
>>> In spite of all the email I've sent up to this point, it dawns on me,
>>> a bit belatedly, that my own configuration file for a worker does list
>>> the components that it expects to find.
>>> 
>>> So, I can set up a protocol where the restful service component waits
>>> for all the components to 'light up' and then lights itself up, since
>>> it knows what is supposed to be there. But not at compile time, so I
>>> can't use a cardinality property.
>>> 
>>> One approach would be to @Reference the list, and then do a little
>>> sleep loop waiting until everyone arrives. I am going to go read on
>>> event admin to see if I can use that to sleep on an event that would
>>> indicate that a new example has shown up.
>>> 
>>> Thanks for all your patience; I think this much will keep me out of
>>> your hair for a while.
>>> 
>>> ---

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

Apparently, I can't read, either. Please ignore the last question I
stuck on the end, which you had just answered.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

On Mon, Sep 7, 2015 at 4:07 PM, David Jencks
 wrote:
> So it looks like we lost most of the thread but to try to keep this from 
> turning into more of a tangled ball of yarn the cat played with….

I'm sorry to be so poor at communicating.
>
>
> 1) NO!:
>
> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
> public void setAllComponents(List allComponents) {
>
>
> This might be a blueprint-ism but DOESNT WORK FOR DS
>
> The event methods (bind/unbind/updated) don’t have to be called anything in 
> particular but they need to take only ONE service/service 
> reference/properties NOT a collection.

Oh, so they get called more than once? Yea, apparently I caught a
social disease from Blueprint!


>
> So
> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
> public void setWorkerComponentService(WorkerComponentService wcs) { …}
>
> If you use DS 1.3 reference fields it can be a collection valued field.  I’ve 
> never used these except possibly in some tests.
>
> 2) the minimum cardinality property has to be supplied from config admin, not 
> component.xml.  So it is runtime modifiable.  I might have missed it but I 
> didn’t see what your configuration was or how you were installing it.  You 
> cannot set the minimum cardinality at compile time.

OK, I get it. That does simplify things.

>
> I think you are making life too hard for yourself.  From your description, 
> when you set up the deployment of your stuff, you know exactly how many 
> WorkerComponentService instances to expect, so you can put that value in the 
> configuration.  Then DS will do the waiting for you, and your restful service 
> component will get the references and activate once the appropriate number 
> are ready.  If you expect to have more WorkerComponentServices registered, 
> say 10, and want to restrict yourself to only using a particular 5 of them, 
> you can, along with the cardinality to assure you get at least 5, use a 
> target filter to find the exact 5 you want.  For instance, if the 
> WorkerComponentServices have a “type” property that identifies which one they 
> are, your filter in the configuration would look something like
>
> WorkerComponentService.cardinality.minimum=5
> WorkerComponentService.target=“(|(type=foo1)(type=foo2)(type=foo3)(type=foo4)(type=foo5))”

Do I really have to enumerate the types if I happen to have
provisioned only the ones I want.

>
> Wiring up DS services is really powerful.  I haven’t figured out the exact 
> computational strength available but to me it has the feel of logic 
> programming.
>
> thanks
> david jencks
>
>
>
>> On Sep 7, 2015, at 2:55 PM, Benson Margulies  wrote:
>>
>> I think I now understand what I have failed to explain here (and I
>> probably know why my service is acting like tantalus).
>>
>> My plan is to create a series of docker containers. Call them
>> 'workers'. Each worker publishes the same restful service; each one of
>> them handles one or more 'tasks'. The worker accepts work via a single
>> RESTful service, and dispatches the work to the tasks based on
>> parameters in the requests to the service.
>>
>> The set of tasks implemented on a particular worker is controlled the
>> set of OSGi bundles I provision in it. I have a whole slew of them,
>> each registers a 'RosetteComponentService'.
>>
>> Each of these task bundles has, potentially, a bit of a startup delay
>> as it gets organized.
>>
>> I don't want to open the restful service until the components are all set up.
>>
>> In spite of all the email I've sent up to this point, it dawns on me,
>> a bit belatedly, that my own configuration file for a worker does list
>> the components that it expects to find.
>>
>> So, I can set up a protocol where the restful service component waits
>> for all the components to 'light up' and then lights itself up, since
>> it knows what is supposed to be there. But not at compile time, so I
>> can't use a cardinality property.
>>
>> One approach would be to @Reference the list, and then do a little
>> sleep loop waiting until everyone arrives. I am going to go read on
>> event admin to see if I can use that to sleep on an event that would
>> indicate that a new example has shown up.
>>
>> Thanks for all your patience; I think this much will keep me out of
>> your hair for a while.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Neil Bartlett]

Hi David,


> On 7 Sep 2015, at 17:45, David Jencks  wrote:
> 
> I think both of those suggestions are rather inappropriate to be used in a DS 
> component activate method, which generally should not block….. although 
> having it take a long time is also very much less than ideal.

I agree, and I never said you should block. By “starting a timer” I certainly 
did NOT mean to imply a call to Thread.sleep()!

> 
> Certainly the second method seems to imply someone knows how many B2s there  
> are so the minimum cardinality can be set based on that knowledge, possibly 
> by whatever code has that knowledge.  The (proprietary) metatype/config admin 
> I work with does this, it can count how many cm Configurations there are for 
> B2 and set properties based on that

Whoever is installing bundles or configurations should know how many there are, 
and it can start and end a coordination. I know that FileInstall doesn’t do 
this. I have also said many times that people shouldn’t be using FileInstall in 
production systems.


> .
> 
> If you make B3 expose a service and not be immediate, then it won’t be 
> activated until someone needs it and will pick up however many are then 
> available, even without the cardinality set.

Yes. I was interested in the use-case where a component has already been 
activated and then its set of dependencies changes dynamically and it needs to 
reconfigure itself.

Regards,
Neil


> 
> david jencks
> 
>> On Sep 7, 2015, at 11:46 AM, Neil Bartlett  wrote:
>> 
>> Just to add a bit of detail…
>> 
>> If you wait for 5 service instances before performing your initialisation, 
>> that’s great. But bear in mind that you might get a 6th and a 7th very soon 
>> afterwards, and depending on your implementation you may have to 
>> re-initialise each time that happens.
>> 
>> If your (re)initialisation is expensive, you might want to avoid doing it 
>> too many times, especially if there is a rapid sequence of changes. This is 
>> typically the case during application startup for example. There are two 
>> general solutions to this:
>> 
>> 1) You could start a timer each time the service set changes. If there are 
>> no further changes before the timer expires, then you do your 
>> reinitialisation. If there *are* changes then you cancel the existing timer 
>> and start a new one.
>> 
>> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter 130). 
>> Whoever is making changes to the set of installed bundles — e.g. the 
>> launcher, or some kind of management agent like FileInstall — should start a 
>> Coordination before it does anything, and end the coordination after that 
>> series of changes. Your component should be a Participant which detects 
>> whether there is a current coordination. If there is NO current coordination 
>> then it should immediately action any changes in the service set. However if 
>> there is a current coordination, then those changes should only be actioned 
>> when the coordination ends. This has the advantage that you don’t waste time 
>> waiting for an arbitrary-length timer to expire.
>> 
>> Hope that helps. Regards,
>> Neil
>> 
>> 
>> 
>>> On 7 Sep 2015, at 16:16, Benson Margulies  wrote:
>>> 
>>> That is precisely what I needed. Thanks.
>>> On Sep 7, 2015 11:06 AM, "David Jencks" 
>>> wrote:
>>> 
 Hi Benson,
 
 I don’t really understand what you are asking, but I’m going to guess.
 
 I think you have say 5  B2 services and you want B3 to wait to activate
 until all 5 B2’s are available?
 
 There is a way to do this with DS 1.3, but you have to make B3
 configuration-policy=REQUIRE.
 
 So you have in B3:
 @Component(configuration-policy=REQUIRE)
 public class B3 {
 
 @Reference(cardinality=MULTIPLE)
 void setB2(B2 b2) {}
 }
 In your (required) configuration for B3 you put a property
 
 B2.cardinality.minimum: 5
 
 that is, .cardinality.minimum = 
 
 Don’t mess with start levels, they will be unreliable for this purpose.
 There’s no guarantee that a bundle starting will start all the DS services
 it provides.  They might have all sorts of unsatisfied dependencies….. such
 as missing configurations.
 
 Let me know if this guess is a total miss :-)
 
 thanks
 david jencks
 
 
 
> On Sep 7, 2015, at 10:52 AM, Benson Margulies 
 wrote:
> 
> I am hoping that David Jencks will continue his charity to strangers
 here.
> 
> David, if you have any gogo jiras you'd like help with in return, just
 ask.
> 
> Three bundles:
> 
> B1 registers service S1.
> 
> B2 consumes S1 and uses it in the implementation of S2. That is to
> say, it picks up a reference to S1 with a DS @Reference with
> cardinality MANDATORY.
> 
> B3 consumes B2, but it anticipates that B2 will have siblings. So it
> consumes a reference to a List with cardinality AT_LEAST_ONE

Re: How to 'let the dust settle' with DS?

[David Jencks]

So it looks like we lost most of the thread but to try to keep this from 
turning into more of a tangled ball of yarn the cat played with….


1) NO!:

@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
public void setAllComponents(List allComponents) {


This might be a blueprint-ism but DOESNT WORK FOR DS

The event methods (bind/unbind/updated) don’t have to be called anything in 
particular but they need to take only ONE service/service reference/properties 
NOT a collection.

So 
@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
public void setWorkerComponentService(WorkerComponentService wcs) { …}

If you use DS 1.3 reference fields it can be a collection valued field.  I’ve 
never used these except possibly in some tests.

2) the minimum cardinality property has to be supplied from config admin, not 
component.xml.  So it is runtime modifiable.  I might have missed it but I 
didn’t see what your configuration was or how you were installing it.  You 
cannot set the minimum cardinality at compile time.

I think you are making life too hard for yourself.  From your description, when 
you set up the deployment of your stuff, you know exactly how many 
WorkerComponentService instances to expect, so you can put that value in the 
configuration.  Then DS will do the waiting for you, and your restful service 
component will get the references and activate once the appropriate number are 
ready.  If you expect to have more WorkerComponentServices registered, say 10, 
and want to restrict yourself to only using a particular 5 of them, you can, 
along with the cardinality to assure you get at least 5, use a target filter to 
find the exact 5 you want.  For instance, if the WorkerComponentServices have a 
“type” property that identifies which one they are, your filter in the 
configuration would look something like

WorkerComponentService.cardinality.minimum=5
WorkerComponentService.target=“(|(type=foo1)(type=foo2)(type=foo3)(type=foo4)(type=foo5))”

Wiring up DS services is really powerful.  I haven’t figured out the exact 
computational strength available but to me it has the feel of logic programming.

thanks
david jencks



> On Sep 7, 2015, at 2:55 PM, Benson Margulies  wrote:
> 
> I think I now understand what I have failed to explain here (and I
> probably know why my service is acting like tantalus).
> 
> My plan is to create a series of docker containers. Call them
> 'workers'. Each worker publishes the same restful service; each one of
> them handles one or more 'tasks'. The worker accepts work via a single
> RESTful service, and dispatches the work to the tasks based on
> parameters in the requests to the service.
> 
> The set of tasks implemented on a particular worker is controlled the
> set of OSGi bundles I provision in it. I have a whole slew of them,
> each registers a 'RosetteComponentService'.
> 
> Each of these task bundles has, potentially, a bit of a startup delay
> as it gets organized.
> 
> I don't want to open the restful service until the components are all set up.
> 
> In spite of all the email I've sent up to this point, it dawns on me,
> a bit belatedly, that my own configuration file for a worker does list
> the components that it expects to find.
> 
> So, I can set up a protocol where the restful service component waits
> for all the components to 'light up' and then lights itself up, since
> it knows what is supposed to be there. But not at compile time, so I
> can't use a cardinality property.
> 
> One approach would be to @Reference the list, and then do a little
> sleep loop waiting until everyone arrives. I am going to go read on
> event admin to see if I can use that to sleep on an event that would
> indicate that a new example has shown up.
> 
> Thanks for all your patience; I think this much will keep me out of
> your hair for a while.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

I think I now understand what I have failed to explain here (and I
probably know why my service is acting like tantalus).

My plan is to create a series of docker containers. Call them
'workers'. Each worker publishes the same restful service; each one of
them handles one or more 'tasks'. The worker accepts work via a single
RESTful service, and dispatches the work to the tasks based on
parameters in the requests to the service.

The set of tasks implemented on a particular worker is controlled the
set of OSGi bundles I provision in it. I have a whole slew of them,
each registers a 'RosetteComponentService'.

Each of these task bundles has, potentially, a bit of a startup delay
as it gets organized.

I don't want to open the restful service until the components are all set up.

In spite of all the email I've sent up to this point, it dawns on me,
a bit belatedly, that my own configuration file for a worker does list
the components that it expects to find.

So, I can set up a protocol where the restful service component waits
for all the components to 'light up' and then lights itself up, since
it knows what is supposed to be there. But not at compile time, so I
can't use a cardinality property.

One approach would be to @Reference the list, and then do a little
sleep loop waiting until everyone arrives. I am going to go read on
event admin to see if I can use that to sleep on an event that would
indicate that a new example has shown up.

Thanks for all your patience; I think this much will keep me out of
your hair for a while.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Scott Lewis]

On 9/7/2015 10:17 AM, Benson Margulies wrote:

On Mon, Sep 7, 2015 at 1:12 PM, David Jencks
 wrote:

If cxf really does not have this capability, which I find hard to believe, I 
would do the “publish to cxf” generically by having a component with a dynamic 
reference (or a service tracker, but if your component is DS a dynamic 
reference is easier) that uses service properties to figure out what to tell 
cxf.

A pretty simple example of how to do this is in the aries imx jmx-whiteboard 
project, which is more complicated than you would need since it has to deal 
with multiple MBean servers whereas I think you would have only one cxf.

I am studying the relevant CXF code now, but I think that the thing
you are looking for (register a service and CXF publishes it) will
exist only if I make it exist.


I haven't followed this whole thread, but it appears like this use case 
(of wanting the registration of an OSGi service to result in an export 
as a REST service) is a good fit for the OSGi R6 Remote Services/RSA 
specifications.  Coincidently, I've recently created a tutorial about a 
new provider that uses the OSGi Remote Services and Jax-RS 
specifications together in this manner [1].


FWIW, I thought that CXF supported some version of the OSGi Remote 
Services/RSA specifications as well as being a Jax-RS impl, but I don't 
know enough about it to comment further.


Scott

[1] 
https://wiki.eclipse.org/Tutorial:_Using_REST_and_OSGi_Standards_for_Micro_Services


>I have made a first pass at coding what you wrote here, but it doesn't 
work yet. What a surprise. More spelunking to do.

thanks
david jencks


On Sep 7, 2015, at 12:46 PM, Benson Margulies  wrote:

On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
mailto:david_jen...@yahoo.com.invalid>> wrote:

I think both of those suggestions are rather inappropriate to be used in a DS 
component activate method, which generally should not block….. although having 
it take a long time is also very much less than ideal.

Certainly the second method seems to imply someone knows how many B2s there  
are so the minimum cardinality can be set based on that knowledge, possibly by 
whatever code has that knowledge.  The (proprietary) metatype/config admin I 
work with does this, it can count how many cm Configurations there are for B2 
and set properties based on that.

If you make B3 expose a service and not be immediate, then it won’t be 
activated until someone needs it and will pick up however many are then 
available, even without the cardinality set.

Dilemma: B3's job in life is to publish a JAX-RS service via CXF,
which does not involve publishing an OSGi service. So I may need to
stick with one of these less-than-ideal alternatives.



david jencks


On Sep 7, 2015, at 11:46 AM, Neil Bartlett  wrote:

Just to add a bit of detail…

If you wait for 5 service instances before performing your initialisation, 
that’s great. But bear in mind that you might get a 6th and a 7th very soon 
afterwards, and depending on your implementation you may have to re-initialise 
each time that happens.

If your (re)initialisation is expensive, you might want to avoid doing it too 
many times, especially if there is a rapid sequence of changes. This is 
typically the case during application startup for example. There are two 
general solutions to this:

1) You could start a timer each time the service set changes. If there are no 
further changes before the timer expires, then you do your reinitialisation. If 
there *are* changes then you cancel the existing timer and start a new one.

2) Use the Coordinator Service (OSGi Compendium Specification, chapter 130). 
Whoever is making changes to the set of installed bundles — e.g. the launcher, 
or some kind of management agent like FileInstall — should start a Coordination 
before it does anything, and end the coordination after that series of changes. 
Your component should be a Participant which detects whether there is a current 
coordination. If there is NO current coordination then it should immediately 
action any changes in the service set. However if there is a current 
coordination, then those changes should only be actioned when the coordination 
ends. This has the advantage that you don’t waste time waiting for an 
arbitrary-length timer to expire.

Hope that helps. Regards,
Neil




On 7 Sep 2015, at 16:16, Benson Margulies  wrote:

That is precisely what I needed. Thanks.
On Sep 7, 2015 11:06 AM, "David Jencks" 
wrote:


Hi Benson,

I don’t really understand what you are asking, but I’m going to guess.

I think you have say 5  B2 services and you want B3 to wait to activate
until all 5 B2’s are available?

There is a way to do this with DS 1.3, but you have to make B3
configuration-policy=REQUIRE.

So you have in B3:
@Component(configuration-policy=REQUIRE)
public class B3 {

@Reference(cardinality=MULTIPLE)
void setB2(B2 b2) {}
}
In your (required) configuration for B3 you put a property

B2.cardinality.minimum: 5

that 

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

The use of REQUIRED seems to be landing me with an unsatisfiable reference.

Here's the situation with the 'B2' service, which seems to be very happy:

 23 | Active   |  76 | 1.5.0.v20150907054257 | rosapi-worker-dummy-sdk
karaf@root>bundle:services 23

rosapi-worker-dummy-sdk (23) provides:
--
[com.basistech.ws.worker.api.WorkerComponentService]


karaf@root>scr:details
com.basistech.ws.sdk.dummy.impl.DummyWorkerComponentServiceImpl
Component Details
  Name:
com.basistech.ws.sdk.dummy.impl.DummyWorkerComponentServiceImpl
  State   : REGISTERED
  Properties  :
component-name=template-tokenization
ComponentService.target=(component-name=template-tokenization)

component.name=com.basistech.ws.sdk.dummy.impl.DummyWorkerComponentServiceImpl
Warmup.target=(component-name=template-tokenization)
component.id=1
References
  Reference   : ComponentService
State : satisfied
Multiple  : single
Optional  : mandatory
Policy: static
Service Reference : No Services bound
  Reference   : Warmup
State : satisfied
Multiple  : single
Optional  : mandatory
Policy: static
Service Reference : No Services bound

For B3:

On my component, I have:

@Component(configurationPolicy = ConfigurationPolicy.REQUIRE,
configurationPid = "com.basistech.ws.worker")

and then:

@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
public void setAllComponents(List allComponents) {

But...


karaf@root>scr:details com.basistech.ws.worker.service.Worker
Component Details
  Name: com.basistech.ws.worker.service.Worker
  State   : UNSATISFIED
  Properties  :
service.pid=com.basistech.ws.worker

configurationFilePathname=/Users/benson/x/rosapi1.5/assemblies/minimal-test/target/assembly/etc/anvils/worker-config.yaml
component.name=com.basistech.ws.worker.service.Worker

felix.fileinstall.filename=file:/Users/benson/x/rosapi1.5/assemblies/minimal-test/target/assembly/etc/com.basistech.ws.worker.cfg
component.id=2
References
  Reference   : AllComponents
State : unsatisfied
Multiple  : multiple
Optional  : mandatory
Policy: static
Service Reference : No Services bound
  Reference   : Bus
State : satisfied
Multiple  : single
Optional  : mandatory
Policy: static
Service Reference : No Services bound

On Mon, Sep 7, 2015 at 1:17 PM, Benson Margulies  wrote:
> On Mon, Sep 7, 2015 at 1:12 PM, David Jencks
>  wrote:
>> If cxf really does not have this capability, which I find hard to believe, I 
>> would do the “publish to cxf” generically by having a component with a 
>> dynamic reference (or a service tracker, but if your component is DS a 
>> dynamic reference is easier) that uses service properties to figure out what 
>> to tell cxf.
>>
>> A pretty simple example of how to do this is in the aries imx jmx-whiteboard 
>> project, which is more complicated than you would need since it has to deal 
>> with multiple MBean servers whereas I think you would have only one cxf.
>
> I am studying the relevant CXF code now, but I think that the thing
> you are looking for (register a service and CXF publishes it) will
> exist only if I make it exist.
>
> I have made a first pass at coding what you wrote here, but it doesn't
> work yet. What a surprise. More spelunking to do.
>
>
>
>>
>> thanks
>> david jencks
>>
>>> On Sep 7, 2015, at 12:46 PM, Benson Margulies  wrote:
>>>
>>> On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
>>> mailto:david_jen...@yahoo.com.invalid>> 
>>> wrote:
 I think both of those suggestions are rather inappropriate to be used in a 
 DS component activate method, which generally should not block….. although 
 having it take a long time is also very much less than ideal.

 Certainly the second method seems to imply someone knows how many B2s 
 there  are so the minimum cardinality can be set based on that knowledge, 
 possibly by whatever code has that knowledge.  The (proprietary) 
 metatype/config admin I work with does this, it can count how many cm 
 Configurations there are for B2 and set properties based on that.

 If you make B3 expose a service and not be immediate, then it won’t be 
 activated until someone needs it and will pick up however many are then 
 available, even without the cardinality set.
>>>
>>> Dilemma: B3's job in life is to publish a JAX-RS service via CXF,
>>> which does not involve publishing an OSGi service. So I may need to
>>> stick with one of these less-than-ideal alternatives.
>>>
>>>

 david jencks

> On Sep 7, 2015, at 11:46 AM, Neil Bartlett  wrote:
>
> Just to add a bit of detail…
>
> If you wait for 5 servi

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

On Mon, Sep 7, 2015 at 1:12 PM, David Jencks
 wrote:
> If cxf really does not have this capability, which I find hard to believe, I 
> would do the “publish to cxf” generically by having a component with a 
> dynamic reference (or a service tracker, but if your component is DS a 
> dynamic reference is easier) that uses service properties to figure out what 
> to tell cxf.
>
> A pretty simple example of how to do this is in the aries imx jmx-whiteboard 
> project, which is more complicated than you would need since it has to deal 
> with multiple MBean servers whereas I think you would have only one cxf.

I am studying the relevant CXF code now, but I think that the thing
you are looking for (register a service and CXF publishes it) will
exist only if I make it exist.

I have made a first pass at coding what you wrote here, but it doesn't
work yet. What a surprise. More spelunking to do.



>
> thanks
> david jencks
>
>> On Sep 7, 2015, at 12:46 PM, Benson Margulies  wrote:
>>
>> On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
>> mailto:david_jen...@yahoo.com.invalid>> 
>> wrote:
>>> I think both of those suggestions are rather inappropriate to be used in a 
>>> DS component activate method, which generally should not block….. although 
>>> having it take a long time is also very much less than ideal.
>>>
>>> Certainly the second method seems to imply someone knows how many B2s there 
>>>  are so the minimum cardinality can be set based on that knowledge, 
>>> possibly by whatever code has that knowledge.  The (proprietary) 
>>> metatype/config admin I work with does this, it can count how many cm 
>>> Configurations there are for B2 and set properties based on that.
>>>
>>> If you make B3 expose a service and not be immediate, then it won’t be 
>>> activated until someone needs it and will pick up however many are then 
>>> available, even without the cardinality set.
>>
>> Dilemma: B3's job in life is to publish a JAX-RS service via CXF,
>> which does not involve publishing an OSGi service. So I may need to
>> stick with one of these less-than-ideal alternatives.
>>
>>
>>>
>>> david jencks
>>>
 On Sep 7, 2015, at 11:46 AM, Neil Bartlett  wrote:

 Just to add a bit of detail…

 If you wait for 5 service instances before performing your initialisation, 
 that’s great. But bear in mind that you might get a 6th and a 7th very 
 soon afterwards, and depending on your implementation you may have to 
 re-initialise each time that happens.

 If your (re)initialisation is expensive, you might want to avoid doing it 
 too many times, especially if there is a rapid sequence of changes. This 
 is typically the case during application startup for example. There are 
 two general solutions to this:

 1) You could start a timer each time the service set changes. If there are 
 no further changes before the timer expires, then you do your 
 reinitialisation. If there *are* changes then you cancel the existing 
 timer and start a new one.

 2) Use the Coordinator Service (OSGi Compendium Specification, chapter 
 130). Whoever is making changes to the set of installed bundles — e.g. the 
 launcher, or some kind of management agent like FileInstall — should start 
 a Coordination before it does anything, and end the coordination after 
 that series of changes. Your component should be a Participant which 
 detects whether there is a current coordination. If there is NO current 
 coordination then it should immediately action any changes in the service 
 set. However if there is a current coordination, then those changes should 
 only be actioned when the coordination ends. This has the advantage that 
 you don’t waste time waiting for an arbitrary-length timer to expire.

 Hope that helps. Regards,
 Neil



> On 7 Sep 2015, at 16:16, Benson Margulies  wrote:
>
> That is precisely what I needed. Thanks.
> On Sep 7, 2015 11:06 AM, "David Jencks" 
> wrote:
>
>> Hi Benson,
>>
>> I don’t really understand what you are asking, but I’m going to guess.
>>
>> I think you have say 5  B2 services and you want B3 to wait to activate
>> until all 5 B2’s are available?
>>
>> There is a way to do this with DS 1.3, but you have to make B3
>> configuration-policy=REQUIRE.
>>
>> So you have in B3:
>> @Component(configuration-policy=REQUIRE)
>> public class B3 {
>>
>> @Reference(cardinality=MULTIPLE)
>> void setB2(B2 b2) {}
>> }
>> In your (required) configuration for B3 you put a property
>>
>> B2.cardinality.minimum: 5
>>
>> that is, .cardinality.minimum = 
>>
>> Don’t mess with start levels, they will be unreliable for this purpose.
>> There’s no guarantee that a bundle starting will start all the DS 
>> services
>> it provides.  They might have all sorts of unsatisfied dep

Re: How to 'let the dust settle' with DS?

[David Jencks]

If cxf really does not have this capability, which I find hard to believe, I 
would do the “publish to cxf” generically by having a component with a dynamic 
reference (or a service tracker, but if your component is DS a dynamic 
reference is easier) that uses service properties to figure out what to tell 
cxf.

A pretty simple example of how to do this is in the aries imx jmx-whiteboard 
project, which is more complicated than you would need since it has to deal 
with multiple MBean servers whereas I think you would have only one cxf.

thanks
david jencks

> On Sep 7, 2015, at 12:46 PM, Benson Margulies  wrote:
> 
> On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
> mailto:david_jen...@yahoo.com.invalid>> 
> wrote:
>> I think both of those suggestions are rather inappropriate to be used in a 
>> DS component activate method, which generally should not block….. although 
>> having it take a long time is also very much less than ideal.
>> 
>> Certainly the second method seems to imply someone knows how many B2s there  
>> are so the minimum cardinality can be set based on that knowledge, possibly 
>> by whatever code has that knowledge.  The (proprietary) metatype/config 
>> admin I work with does this, it can count how many cm Configurations there 
>> are for B2 and set properties based on that.
>> 
>> If you make B3 expose a service and not be immediate, then it won’t be 
>> activated until someone needs it and will pick up however many are then 
>> available, even without the cardinality set.
> 
> Dilemma: B3's job in life is to publish a JAX-RS service via CXF,
> which does not involve publishing an OSGi service. So I may need to
> stick with one of these less-than-ideal alternatives.
> 
> 
>> 
>> david jencks
>> 
>>> On Sep 7, 2015, at 11:46 AM, Neil Bartlett  wrote:
>>> 
>>> Just to add a bit of detail…
>>> 
>>> If you wait for 5 service instances before performing your initialisation, 
>>> that’s great. But bear in mind that you might get a 6th and a 7th very soon 
>>> afterwards, and depending on your implementation you may have to 
>>> re-initialise each time that happens.
>>> 
>>> If your (re)initialisation is expensive, you might want to avoid doing it 
>>> too many times, especially if there is a rapid sequence of changes. This is 
>>> typically the case during application startup for example. There are two 
>>> general solutions to this:
>>> 
>>> 1) You could start a timer each time the service set changes. If there are 
>>> no further changes before the timer expires, then you do your 
>>> reinitialisation. If there *are* changes then you cancel the existing timer 
>>> and start a new one.
>>> 
>>> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter 
>>> 130). Whoever is making changes to the set of installed bundles — e.g. the 
>>> launcher, or some kind of management agent like FileInstall — should start 
>>> a Coordination before it does anything, and end the coordination after that 
>>> series of changes. Your component should be a Participant which detects 
>>> whether there is a current coordination. If there is NO current 
>>> coordination then it should immediately action any changes in the service 
>>> set. However if there is a current coordination, then those changes should 
>>> only be actioned when the coordination ends. This has the advantage that 
>>> you don’t waste time waiting for an arbitrary-length timer to expire.
>>> 
>>> Hope that helps. Regards,
>>> Neil
>>> 
>>> 
>>> 
 On 7 Sep 2015, at 16:16, Benson Margulies  wrote:
 
 That is precisely what I needed. Thanks.
 On Sep 7, 2015 11:06 AM, "David Jencks" 
 wrote:
 
> Hi Benson,
> 
> I don’t really understand what you are asking, but I’m going to guess.
> 
> I think you have say 5  B2 services and you want B3 to wait to activate
> until all 5 B2’s are available?
> 
> There is a way to do this with DS 1.3, but you have to make B3
> configuration-policy=REQUIRE.
> 
> So you have in B3:
> @Component(configuration-policy=REQUIRE)
> public class B3 {
> 
> @Reference(cardinality=MULTIPLE)
> void setB2(B2 b2) {}
> }
> In your (required) configuration for B3 you put a property
> 
> B2.cardinality.minimum: 5
> 
> that is, .cardinality.minimum = 
> 
> Don’t mess with start levels, they will be unreliable for this purpose.
> There’s no guarantee that a bundle starting will start all the DS services
> it provides.  They might have all sorts of unsatisfied dependencies….. 
> such
> as missing configurations.
> 
> Let me know if this guess is a total miss :-)
> 
> thanks
> david jencks
> 
> 
> 
>> On Sep 7, 2015, at 10:52 AM, Benson Margulies 
> wrote:
>> 
>> I am hoping that David Jencks will continue his charity to strangers
> here.
>> 
>> David, if you have any gogo jiras you'd like help with in return, just
> ask.
>>

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
 wrote:
> I think both of those suggestions are rather inappropriate to be used in a DS 
> component activate method, which generally should not block….. although 
> having it take a long time is also very much less than ideal.
>
> Certainly the second method seems to imply someone knows how many B2s there  
> are so the minimum cardinality can be set based on that knowledge, possibly 
> by whatever code has that knowledge.  The (proprietary) metatype/config admin 
> I work with does this, it can count how many cm Configurations there are for 
> B2 and set properties based on that.
>
> If you make B3 expose a service and not be immediate, then it won’t be 
> activated until someone needs it and will pick up however many are then 
> available, even without the cardinality set.

Dilemma: B3's job in life is to publish a JAX-RS service via CXF,
which does not involve publishing an OSGi service. So I may need to
stick with one of these less-than-ideal alternatives.


>
> david jencks
>
>> On Sep 7, 2015, at 11:46 AM, Neil Bartlett  wrote:
>>
>> Just to add a bit of detail…
>>
>> If you wait for 5 service instances before performing your initialisation, 
>> that’s great. But bear in mind that you might get a 6th and a 7th very soon 
>> afterwards, and depending on your implementation you may have to 
>> re-initialise each time that happens.
>>
>> If your (re)initialisation is expensive, you might want to avoid doing it 
>> too many times, especially if there is a rapid sequence of changes. This is 
>> typically the case during application startup for example. There are two 
>> general solutions to this:
>>
>> 1) You could start a timer each time the service set changes. If there are 
>> no further changes before the timer expires, then you do your 
>> reinitialisation. If there *are* changes then you cancel the existing timer 
>> and start a new one.
>>
>> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter 130). 
>> Whoever is making changes to the set of installed bundles — e.g. the 
>> launcher, or some kind of management agent like FileInstall — should start a 
>> Coordination before it does anything, and end the coordination after that 
>> series of changes. Your component should be a Participant which detects 
>> whether there is a current coordination. If there is NO current coordination 
>> then it should immediately action any changes in the service set. However if 
>> there is a current coordination, then those changes should only be actioned 
>> when the coordination ends. This has the advantage that you don’t waste time 
>> waiting for an arbitrary-length timer to expire.
>>
>> Hope that helps. Regards,
>> Neil
>>
>>
>>
>>> On 7 Sep 2015, at 16:16, Benson Margulies  wrote:
>>>
>>> That is precisely what I needed. Thanks.
>>> On Sep 7, 2015 11:06 AM, "David Jencks" 
>>> wrote:
>>>
 Hi Benson,

 I don’t really understand what you are asking, but I’m going to guess.

 I think you have say 5  B2 services and you want B3 to wait to activate
 until all 5 B2’s are available?

 There is a way to do this with DS 1.3, but you have to make B3
 configuration-policy=REQUIRE.

 So you have in B3:
 @Component(configuration-policy=REQUIRE)
 public class B3 {

 @Reference(cardinality=MULTIPLE)
 void setB2(B2 b2) {}
 }
 In your (required) configuration for B3 you put a property

 B2.cardinality.minimum: 5

 that is, .cardinality.minimum = 

 Don’t mess with start levels, they will be unreliable for this purpose.
 There’s no guarantee that a bundle starting will start all the DS services
 it provides.  They might have all sorts of unsatisfied dependencies….. such
 as missing configurations.

 Let me know if this guess is a total miss :-)

 thanks
 david jencks



> On Sep 7, 2015, at 10:52 AM, Benson Margulies 
 wrote:
>
> I am hoping that David Jencks will continue his charity to strangers
 here.
>
> David, if you have any gogo jiras you'd like help with in return, just
 ask.
>
> Three bundles:
>
> B1 registers service S1.
>
> B2 consumes S1 and uses it in the implementation of S2. That is to
> say, it picks up a reference to S1 with a DS @Reference with
> cardinality MANDATORY.
>
> B3 consumes B2, but it anticipates that B2 will have siblings. So it
> consumes a reference to a List with cardinality AT_LEAST_ONE.
>
> It can take B2 and buddies a bit of time to activate.
>
> I appreciate that the most general case is intended to be that
> services come and go, and B3 should dynamically reconfigure itself.
> I'd rather not do that yet; I'd like to arrange things so that B3
> waits to finish starting itself until all the B2-ish guys are fully
> set up.
>
> Assuming that B2 and friends are all started at a

Re: How to 'let the dust settle' with DS?

[David Jencks]

I think both of those suggestions are rather inappropriate to be used in a DS 
component activate method, which generally should not block….. although having 
it take a long time is also very much less than ideal.

Certainly the second method seems to imply someone knows how many B2s there  
are so the minimum cardinality can be set based on that knowledge, possibly by 
whatever code has that knowledge.  The (proprietary) metatype/config admin I 
work with does this, it can count how many cm Configurations there are for B2 
and set properties based on that.

If you make B3 expose a service and not be immediate, then it won’t be 
activated until someone needs it and will pick up however many are then 
available, even without the cardinality set.

david jencks

> On Sep 7, 2015, at 11:46 AM, Neil Bartlett  wrote:
> 
> Just to add a bit of detail…
> 
> If you wait for 5 service instances before performing your initialisation, 
> that’s great. But bear in mind that you might get a 6th and a 7th very soon 
> afterwards, and depending on your implementation you may have to 
> re-initialise each time that happens.
> 
> If your (re)initialisation is expensive, you might want to avoid doing it too 
> many times, especially if there is a rapid sequence of changes. This is 
> typically the case during application startup for example. There are two 
> general solutions to this:
> 
> 1) You could start a timer each time the service set changes. If there are no 
> further changes before the timer expires, then you do your reinitialisation. 
> If there *are* changes then you cancel the existing timer and start a new one.
> 
> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter 130). 
> Whoever is making changes to the set of installed bundles — e.g. the 
> launcher, or some kind of management agent like FileInstall — should start a 
> Coordination before it does anything, and end the coordination after that 
> series of changes. Your component should be a Participant which detects 
> whether there is a current coordination. If there is NO current coordination 
> then it should immediately action any changes in the service set. However if 
> there is a current coordination, then those changes should only be actioned 
> when the coordination ends. This has the advantage that you don’t waste time 
> waiting for an arbitrary-length timer to expire.
> 
> Hope that helps. Regards,
> Neil
> 
> 
> 
>> On 7 Sep 2015, at 16:16, Benson Margulies  wrote:
>> 
>> That is precisely what I needed. Thanks.
>> On Sep 7, 2015 11:06 AM, "David Jencks" 
>> wrote:
>> 
>>> Hi Benson,
>>> 
>>> I don’t really understand what you are asking, but I’m going to guess.
>>> 
>>> I think you have say 5  B2 services and you want B3 to wait to activate
>>> until all 5 B2’s are available?
>>> 
>>> There is a way to do this with DS 1.3, but you have to make B3
>>> configuration-policy=REQUIRE.
>>> 
>>> So you have in B3:
>>> @Component(configuration-policy=REQUIRE)
>>> public class B3 {
>>> 
>>> @Reference(cardinality=MULTIPLE)
>>> void setB2(B2 b2) {}
>>> }
>>> In your (required) configuration for B3 you put a property
>>> 
>>> B2.cardinality.minimum: 5
>>> 
>>> that is, .cardinality.minimum = 
>>> 
>>> Don’t mess with start levels, they will be unreliable for this purpose.
>>> There’s no guarantee that a bundle starting will start all the DS services
>>> it provides.  They might have all sorts of unsatisfied dependencies….. such
>>> as missing configurations.
>>> 
>>> Let me know if this guess is a total miss :-)
>>> 
>>> thanks
>>> david jencks
>>> 
>>> 
>>> 
 On Sep 7, 2015, at 10:52 AM, Benson Margulies 
>>> wrote:
 
 I am hoping that David Jencks will continue his charity to strangers
>>> here.
 
 David, if you have any gogo jiras you'd like help with in return, just
>>> ask.
 
 Three bundles:
 
 B1 registers service S1.
 
 B2 consumes S1 and uses it in the implementation of S2. That is to
 say, it picks up a reference to S1 with a DS @Reference with
 cardinality MANDATORY.
 
 B3 consumes B2, but it anticipates that B2 will have siblings. So it
 consumes a reference to a List with cardinality AT_LEAST_ONE.
 
 It can take B2 and buddies a bit of time to activate.
 
 I appreciate that the most general case is intended to be that
 services come and go, and B3 should dynamically reconfigure itself.
 I'd rather not do that yet; I'd like to arrange things so that B3
 waits to finish starting itself until all the B2-ish guys are fully
 set up.
 
 Assuming that B2 and friends are all started at an earlier start
 level, is there an 'esthetic' way to arrange this? Or should I really
 suck it up and do the late-binding so that B3 says, 'OK, _now_ I need
 B2 service x=y, block until it's available?'
 
 -
 To unsubscribe, e-mail: users-unsubscr...@feli

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

On Mon, Sep 7, 2015 at 11:46 AM, Neil Bartlett  wrote:
> Just to add a bit of detail…
>
> If you wait for 5 service instances before performing your initialisation, 
> that’s great. But bear in mind that you might get a 6th and a 7th very soon 
> afterwards, and depending on your implementation you may have to 
> re-initialise each time that happens.
>
> If your (re)initialisation is expensive, you might want to avoid doing it too 
> many times, especially if there is a rapid sequence of changes. This is 
> typically the case during application startup for example. There are two 
> general solutions to this:
>
> 1) You could start a timer each time the service set changes. If there are no 
> further changes before the timer expires, then you do your reinitialisation. 
> If there *are* changes then you cancel the existing timer and start a new one.
>
> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter 130). 
> Whoever is making changes to the set of installed bundles — e.g. the 
> launcher, or some kind of management agent like FileInstall — should start a 
> Coordination before it does anything, and end the coordination after that 
> series of changes. Your component should be a Participant which detects 
> whether there is a current coordination. If there is NO current coordination 
> then it should immediately action any changes in the service set. However if 
> there is a current coordination, then those changes should only be actioned 
> when the coordination ends. This has the advantage that you don’t waste time 
> waiting for an arbitrary-length timer to expire.
>
> Hope that helps. Regards,
> Neil

Neil, thanks.

To begin with, I'm going to have a static collection of services
present in the Karaf container via the Karaf assembly mechanism. I
just need to start up in an orderly way with them. I may never need or
want to add or subtract on the fly.


>
>
>
>> On 7 Sep 2015, at 16:16, Benson Margulies  wrote:
>>
>> That is precisely what I needed. Thanks.
>> On Sep 7, 2015 11:06 AM, "David Jencks" 
>> wrote:
>>
>>> Hi Benson,
>>>
>>> I don’t really understand what you are asking, but I’m going to guess.
>>>
>>> I think you have say 5  B2 services and you want B3 to wait to activate
>>> until all 5 B2’s are available?
>>>
>>> There is a way to do this with DS 1.3, but you have to make B3
>>> configuration-policy=REQUIRE.
>>>
>>> So you have in B3:
>>> @Component(configuration-policy=REQUIRE)
>>> public class B3 {
>>>
>>> @Reference(cardinality=MULTIPLE)
>>> void setB2(B2 b2) {}
>>> }
>>> In your (required) configuration for B3 you put a property
>>>
>>> B2.cardinality.minimum: 5
>>>
>>> that is, .cardinality.minimum = 
>>>
>>> Don’t mess with start levels, they will be unreliable for this purpose.
>>> There’s no guarantee that a bundle starting will start all the DS services
>>> it provides.  They might have all sorts of unsatisfied dependencies….. such
>>> as missing configurations.
>>>
>>> Let me know if this guess is a total miss :-)
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
 On Sep 7, 2015, at 10:52 AM, Benson Margulies 
>>> wrote:

 I am hoping that David Jencks will continue his charity to strangers
>>> here.

 David, if you have any gogo jiras you'd like help with in return, just
>>> ask.

 Three bundles:

 B1 registers service S1.

 B2 consumes S1 and uses it in the implementation of S2. That is to
 say, it picks up a reference to S1 with a DS @Reference with
 cardinality MANDATORY.

 B3 consumes B2, but it anticipates that B2 will have siblings. So it
 consumes a reference to a List with cardinality AT_LEAST_ONE.

 It can take B2 and buddies a bit of time to activate.

 I appreciate that the most general case is intended to be that
 services come and go, and B3 should dynamically reconfigure itself.
 I'd rather not do that yet; I'd like to arrange things so that B3
 waits to finish starting itself until all the B2-ish guys are fully
 set up.

 Assuming that B2 and friends are all started at an earlier start
 level, is there an 'esthetic' way to arrange this? Or should I really
 suck it up and do the late-binding so that B3 says, 'OK, _now_ I need
 B2 service x=y, block until it's available?'

 -
 To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
 For additional commands, e-mail: users-h...@felix.apache.org

>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

--

Re: How to 'let the dust settle' with DS?

[Neil Bartlett]

Just to add a bit of detail…

If you wait for 5 service instances before performing your initialisation, 
that’s great. But bear in mind that you might get a 6th and a 7th very soon 
afterwards, and depending on your implementation you may have to re-initialise 
each time that happens.

If your (re)initialisation is expensive, you might want to avoid doing it too 
many times, especially if there is a rapid sequence of changes. This is 
typically the case during application startup for example. There are two 
general solutions to this:

1) You could start a timer each time the service set changes. If there are no 
further changes before the timer expires, then you do your reinitialisation. If 
there *are* changes then you cancel the existing timer and start a new one.

2) Use the Coordinator Service (OSGi Compendium Specification, chapter 130). 
Whoever is making changes to the set of installed bundles — e.g. the launcher, 
or some kind of management agent like FileInstall — should start a Coordination 
before it does anything, and end the coordination after that series of changes. 
Your component should be a Participant which detects whether there is a current 
coordination. If there is NO current coordination then it should immediately 
action any changes in the service set. However if there is a current 
coordination, then those changes should only be actioned when the coordination 
ends. This has the advantage that you don’t waste time waiting for an 
arbitrary-length timer to expire.

Hope that helps. Regards,
Neil



> On 7 Sep 2015, at 16:16, Benson Margulies  wrote:
> 
> That is precisely what I needed. Thanks.
> On Sep 7, 2015 11:06 AM, "David Jencks" 
> wrote:
> 
>> Hi Benson,
>> 
>> I don’t really understand what you are asking, but I’m going to guess.
>> 
>> I think you have say 5  B2 services and you want B3 to wait to activate
>> until all 5 B2’s are available?
>> 
>> There is a way to do this with DS 1.3, but you have to make B3
>> configuration-policy=REQUIRE.
>> 
>> So you have in B3:
>> @Component(configuration-policy=REQUIRE)
>> public class B3 {
>> 
>> @Reference(cardinality=MULTIPLE)
>> void setB2(B2 b2) {}
>> }
>> In your (required) configuration for B3 you put a property
>> 
>> B2.cardinality.minimum: 5
>> 
>> that is, .cardinality.minimum = 
>> 
>> Don’t mess with start levels, they will be unreliable for this purpose.
>> There’s no guarantee that a bundle starting will start all the DS services
>> it provides.  They might have all sorts of unsatisfied dependencies….. such
>> as missing configurations.
>> 
>> Let me know if this guess is a total miss :-)
>> 
>> thanks
>> david jencks
>> 
>> 
>> 
>>> On Sep 7, 2015, at 10:52 AM, Benson Margulies 
>> wrote:
>>> 
>>> I am hoping that David Jencks will continue his charity to strangers
>> here.
>>> 
>>> David, if you have any gogo jiras you'd like help with in return, just
>> ask.
>>> 
>>> Three bundles:
>>> 
>>> B1 registers service S1.
>>> 
>>> B2 consumes S1 and uses it in the implementation of S2. That is to
>>> say, it picks up a reference to S1 with a DS @Reference with
>>> cardinality MANDATORY.
>>> 
>>> B3 consumes B2, but it anticipates that B2 will have siblings. So it
>>> consumes a reference to a List with cardinality AT_LEAST_ONE.
>>> 
>>> It can take B2 and buddies a bit of time to activate.
>>> 
>>> I appreciate that the most general case is intended to be that
>>> services come and go, and B3 should dynamically reconfigure itself.
>>> I'd rather not do that yet; I'd like to arrange things so that B3
>>> waits to finish starting itself until all the B2-ish guys are fully
>>> set up.
>>> 
>>> Assuming that B2 and friends are all started at an earlier start
>>> level, is there an 'esthetic' way to arrange this? Or should I really
>>> suck it up and do the late-binding so that B3 says, 'OK, _now_ I need
>>> B2 service x=y, block until it's available?'
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

That is precisely what I needed. Thanks.
On Sep 7, 2015 11:06 AM, "David Jencks" 
wrote:

> Hi Benson,
>
> I don’t really understand what you are asking, but I’m going to guess.
>
> I think you have say 5  B2 services and you want B3 to wait to activate
> until all 5 B2’s are available?
>
> There is a way to do this with DS 1.3, but you have to make B3
> configuration-policy=REQUIRE.
>
> So you have in B3:
> @Component(configuration-policy=REQUIRE)
> public class B3 {
>
> @Reference(cardinality=MULTIPLE)
> void setB2(B2 b2) {}
> }
> In your (required) configuration for B3 you put a property
>
> B2.cardinality.minimum: 5
>
> that is, .cardinality.minimum = 
>
> Don’t mess with start levels, they will be unreliable for this purpose.
> There’s no guarantee that a bundle starting will start all the DS services
> it provides.  They might have all sorts of unsatisfied dependencies….. such
> as missing configurations.
>
> Let me know if this guess is a total miss :-)
>
> thanks
> david jencks
>
>
>
> > On Sep 7, 2015, at 10:52 AM, Benson Margulies 
> wrote:
> >
> > I am hoping that David Jencks will continue his charity to strangers
> here.
> >
> > David, if you have any gogo jiras you'd like help with in return, just
> ask.
> >
> > Three bundles:
> >
> > B1 registers service S1.
> >
> > B2 consumes S1 and uses it in the implementation of S2. That is to
> > say, it picks up a reference to S1 with a DS @Reference with
> > cardinality MANDATORY.
> >
> > B3 consumes B2, but it anticipates that B2 will have siblings. So it
> > consumes a reference to a List with cardinality AT_LEAST_ONE.
> >
> > It can take B2 and buddies a bit of time to activate.
> >
> > I appreciate that the most general case is intended to be that
> > services come and go, and B3 should dynamically reconfigure itself.
> > I'd rather not do that yet; I'd like to arrange things so that B3
> > waits to finish starting itself until all the B2-ish guys are fully
> > set up.
> >
> > Assuming that B2 and friends are all started at an earlier start
> > level, is there an 'esthetic' way to arrange this? Or should I really
> > suck it up and do the late-binding so that B3 says, 'OK, _now_ I need
> > B2 service x=y, block until it's available?'
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: How to 'let the dust settle' with DS?

[David Jencks]

Hi Benson,

I don’t really understand what you are asking, but I’m going to guess.

I think you have say 5  B2 services and you want B3 to wait to activate until 
all 5 B2’s are available?

There is a way to do this with DS 1.3, but you have to make B3 
configuration-policy=REQUIRE.

So you have in B3:
@Component(configuration-policy=REQUIRE)
public class B3 {

@Reference(cardinality=MULTIPLE)
void setB2(B2 b2) {}
}
In your (required) configuration for B3 you put a property

B2.cardinality.minimum: 5

that is, .cardinality.minimum = 

Don’t mess with start levels, they will be unreliable for this purpose.  
There’s no guarantee that a bundle starting will start all the DS services it 
provides.  They might have all sorts of unsatisfied dependencies….. such as 
missing configurations.

Let me know if this guess is a total miss :-)

thanks
david jencks



> On Sep 7, 2015, at 10:52 AM, Benson Margulies  wrote:
> 
> I am hoping that David Jencks will continue his charity to strangers here.
> 
> David, if you have any gogo jiras you'd like help with in return, just ask.
> 
> Three bundles:
> 
> B1 registers service S1.
> 
> B2 consumes S1 and uses it in the implementation of S2. That is to
> say, it picks up a reference to S1 with a DS @Reference with
> cardinality MANDATORY.
> 
> B3 consumes B2, but it anticipates that B2 will have siblings. So it
> consumes a reference to a List with cardinality AT_LEAST_ONE.
> 
> It can take B2 and buddies a bit of time to activate.
> 
> I appreciate that the most general case is intended to be that
> services come and go, and B3 should dynamically reconfigure itself.
> I'd rather not do that yet; I'd like to arrange things so that B3
> waits to finish starting itself until all the B2-ish guys are fully
> set up.
> 
> Assuming that B2 and friends are all started at an earlier start
> level, is there an 'esthetic' way to arrange this? Or should I really
> suck it up and do the late-binding so that B3 says, 'OK, _now_ I need
> B2 service x=y, block until it's available?'
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

How to 'let the dust settle' with DS?

[Benson Margulies]

I am hoping that David Jencks will continue his charity to strangers here.

David, if you have any gogo jiras you'd like help with in return, just ask.

Three bundles:

B1 registers service S1.

B2 consumes S1 and uses it in the implementation of S2. That is to
say, it picks up a reference to S1 with a DS @Reference with
cardinality MANDATORY.

B3 consumes B2, but it anticipates that B2 will have siblings. So it
consumes a reference to a List with cardinality AT_LEAST_ONE.

It can take B2 and buddies a bit of time to activate.

I appreciate that the most general case is intended to be that
services come and go, and B3 should dynamically reconfigure itself.
I'd rather not do that yet; I'd like to arrange things so that B3
waits to finish starting itself until all the B2-ish guys are fully
set up.

Assuming that B2 and friends are all started at an earlier start
level, is there an 'esthetic' way to arrange this? Or should I really
suck it up and do the late-binding so that B3 says, 'OK, _now_ I need
B2 service x=y, block until it's available?'

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org