Hi David,
> On 7 Sep 2015, at 17:45, David Jencks <[email protected]> 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 <[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 >> >> >> >>> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
