On Mon, Sep 7, 2015 at 11:46 AM, Neil Bartlett <[email protected]> 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 <[email protected]> wrote: >> >> That is precisely what I needed. Thanks. >> On Sep 7, 2015 11:06 AM, "David Jencks" <[email protected]> >> 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 <[email protected]> >>> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
