You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Benson Margulies <be...@basistech.com> on 2015/09/07 16:52:42 UTC
How to 'let the dust settle' with DS?
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<S2> 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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by David Leangen <os...@leangen.net>.
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Neil Bartlett <nj...@gmail.com>.
Hi David,
> On 7 Sep 2015, at 17:45, David Jencks <da...@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.
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 <nj...@gmail.com> 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 <be...@basistech.com> wrote:
>>>
>>> That is precisely what I needed. Thanks.
>>> On Sep 7, 2015 11:06 AM, "David Jencks" <da...@yahoo.com.invalid>
>>> 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, <reference-name>.cardinality.minimum = <number of required B2’s>
>>>>
>>>> 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 <be...@basistech.com>
>>>> 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<S2> 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-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
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<WorkerComponentService> 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 <be...@basistech.com> wrote:
> On Mon, Sep 7, 2015 at 1:12 PM, David Jencks
> <da...@yahoo.com.invalid> 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 <be...@basistech.com> wrote:
>>>
>>> On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
>>> <david_jencks@yahoo.com.invalid <ma...@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 <nj...@gmail.com> 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 <be...@basistech.com> wrote:
>>>>>>
>>>>>> That is precisely what I needed. Thanks.
>>>>>> On Sep 7, 2015 11:06 AM, "David Jencks" <da...@yahoo.com.invalid>
>>>>>> 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, <reference-name>.cardinality.minimum = <number of required B2’s>
>>>>>>>
>>>>>>> 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 <be...@basistech.com>
>>>>>>> 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<S2> 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-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>>>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
This is easy to explain. The version of felix scr in karaf is too old.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
The whole thing works with 1.8.2; I look forward to some cleanup with
2.0, and I thank you all again for all the help.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
On Tue, Sep 8, 2015 at 1:47 PM, David Jencks <da...@gmail.com> wrote:
> If the reference is static greedy, then the component having the reference has to be deactivated/reactivated each time the set of available services changes.
>
> If the component exposes a service, and is not immediate, then each get/unget cycle will result in activating/deactivating the instance.
>
> You need to include a lot more information about exactly what your components look like and the circumstances around the behavior you report to assign a specific cause to it.
OK, I've got it; that's exactly the situation at hand (static greedy).
That works for me for now until I can use the newer version.
>
> thanks
> david jencks
>
>> On Sep 8, 2015, at 1:23 PM, Benson Margulies <be...@basistech.com> wrote:
>>
>> JB says he'll have Karaf up to date next week. In the mean time, I've
>> onto the second chunk of blueprint that I wanted to fix.
>>
>> This time, all in one bundle, I have one multiple @Reference, and a
>> bundle of services that want to feed into it.
>>
>> I observe that an object is created, activate is called, and then
>> deactivate is called.
>> Then a new object is created, and the @Reference method gets called
>> before activate is called.
>>
>> Can you help me find the place in the spec that explains this lifecycle?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by David Jencks <da...@gmail.com>.
If the reference is static greedy, then the component having the reference has to be deactivated/reactivated each time the set of available services changes.
If the component exposes a service, and is not immediate, then each get/unget cycle will result in activating/deactivating the instance.
You need to include a lot more information about exactly what your components look like and the circumstances around the behavior you report to assign a specific cause to it.
thanks
david jencks
> On Sep 8, 2015, at 1:23 PM, Benson Margulies <be...@basistech.com> wrote:
>
> JB says he'll have Karaf up to date next week. In the mean time, I've
> onto the second chunk of blueprint that I wanted to fix.
>
> This time, all in one bundle, I have one multiple @Reference, and a
> bundle of services that want to feed into it.
>
> I observe that an object is created, activate is called, and then
> deactivate is called.
> Then a new object is created, and the @Reference method gets called
> before activate is called.
>
> Can you help me find the place in the spec that explains this lifecycle?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
JB says he'll have Karaf up to date next week. In the mean time, I've
onto the second chunk of blueprint that I wanted to fix.
This time, all in one bundle, I have one multiple @Reference, and a
bundle of services that want to feed into it.
I observe that an object is created, activate is called, and then
deactivate is called.
Then a new object is created, and the @Reference method gets called
before activate is called.
Can you help me find the place in the spec that explains this lifecycle?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by David Jencks <da...@gmail.com>.
> On Sep 7, 2015, at 8:07 PM, Benson Margulies <be...@basistech.com> 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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by David Jencks <da...@yahoo.com.INVALID>.
> On Sep 7, 2015, at 5:06 PM, Benson Margulies <benson@basistech.com <ma...@basistech.com>> wrote:
>
> On Mon, Sep 7, 2015 at 4:07 PM, David Jencks
> <david_jencks@yahoo.com.invalid <ma...@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<WorkerComponentService> 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 <benson@basistech.com <ma...@basistech.com>> 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-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
On Mon, Sep 7, 2015 at 4:07 PM, David Jencks
<da...@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<WorkerComponentService> 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 <be...@basistech.com> 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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by David Jencks <da...@yahoo.com.INVALID>.
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<WorkerComponentService> 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 <be...@basistech.com> 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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Scott Lewis <sl...@composent.com>.
On 9/7/2015 10:17 AM, Benson Margulies wrote:
> On Mon, Sep 7, 2015 at 1:12 PM, David Jencks
> <da...@yahoo.com.invalid> 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 <be...@basistech.com> wrote:
>>>
>>> On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
>>> <david_jencks@yahoo.com.invalid <ma...@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 <nj...@gmail.com> 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 <be...@basistech.com> wrote:
>>>>>>
>>>>>> That is precisely what I needed. Thanks.
>>>>>> On Sep 7, 2015 11:06 AM, "David Jencks" <da...@yahoo.com.invalid>
>>>>>> 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, <reference-name>.cardinality.minimum = <number of required B2’s>
>>>>>>>
>>>>>>> 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 <be...@basistech.com>
>>>>>>> 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<S2> 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-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>>>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
On Mon, Sep 7, 2015 at 1:12 PM, David Jencks
<da...@yahoo.com.invalid> 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 <be...@basistech.com> wrote:
>>
>> On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
>> <david_jencks@yahoo.com.invalid <ma...@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 <nj...@gmail.com> 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 <be...@basistech.com> wrote:
>>>>>
>>>>> That is precisely what I needed. Thanks.
>>>>> On Sep 7, 2015 11:06 AM, "David Jencks" <da...@yahoo.com.invalid>
>>>>> 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, <reference-name>.cardinality.minimum = <number of required B2’s>
>>>>>>
>>>>>> 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 <be...@basistech.com>
>>>>>> 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<S2> 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-unsubscribe@felix.apache.org
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by David Jencks <da...@yahoo.com.INVALID>.
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 <be...@basistech.com> wrote:
>
> On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
> <david_jencks@yahoo.com.invalid <ma...@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 <nj...@gmail.com> 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 <be...@basistech.com> wrote:
>>>>
>>>> That is precisely what I needed. Thanks.
>>>> On Sep 7, 2015 11:06 AM, "David Jencks" <da...@yahoo.com.invalid>
>>>> 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, <reference-name>.cardinality.minimum = <number of required B2’s>
>>>>>
>>>>> 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 <be...@basistech.com>
>>>>> 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<S2> 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-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
<da...@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 <nj...@gmail.com> 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 <be...@basistech.com> wrote:
>>>
>>> That is precisely what I needed. Thanks.
>>> On Sep 7, 2015 11:06 AM, "David Jencks" <da...@yahoo.com.invalid>
>>> 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, <reference-name>.cardinality.minimum = <number of required B2’s>
>>>>
>>>> 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 <be...@basistech.com>
>>>> 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<S2> 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-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by David Jencks <da...@yahoo.com.INVALID>.
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 <nj...@gmail.com> 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 <be...@basistech.com> wrote:
>>
>> That is precisely what I needed. Thanks.
>> On Sep 7, 2015 11:06 AM, "David Jencks" <da...@yahoo.com.invalid>
>> 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, <reference-name>.cardinality.minimum = <number of required B2’s>
>>>
>>> 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 <be...@basistech.com>
>>> 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<S2> 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-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
On Mon, Sep 7, 2015 at 11:46 AM, Neil Bartlett <nj...@gmail.com> 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 <be...@basistech.com> wrote:
>>
>> That is precisely what I needed. Thanks.
>> On Sep 7, 2015 11:06 AM, "David Jencks" <da...@yahoo.com.invalid>
>> 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, <reference-name>.cardinality.minimum = <number of required B2’s>
>>>
>>> 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 <be...@basistech.com>
>>> 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<S2> 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-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Neil Bartlett <nj...@gmail.com>.
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 <be...@basistech.com> wrote:
>
> That is precisely what I needed. Thanks.
> On Sep 7, 2015 11:06 AM, "David Jencks" <da...@yahoo.com.invalid>
> 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, <reference-name>.cardinality.minimum = <number of required B2’s>
>>
>> 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 <be...@basistech.com>
>> 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<S2> 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-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How to 'let the dust settle' with DS?
Posted by Benson Margulies <be...@basistech.com>.
That is precisely what I needed. Thanks.
On Sep 7, 2015 11:06 AM, "David Jencks" <da...@yahoo.com.invalid>
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, <reference-name>.cardinality.minimum = <number of required B2’s>
>
> 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 <be...@basistech.com>
> 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<S2> 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-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: How to 'let the dust settle' with DS?
Posted by David Jencks <da...@yahoo.com.INVALID>.
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, <reference-name>.cardinality.minimum = <number of required B2’s>
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 <be...@basistech.com> 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<S2> 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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org