I’m not sure if my suggestion would continue to work i R7 due to coordination support.
david jencks > On Jan 9, 2017, at 11:46 AM, David Jencks <david.a.jen...@gmail.com> wrote: > > Felix DS runs off the configuration events too, so just waiting for the > events isn’t going to determine whether you or DS is notified first. > > I’m not sure if you can use serviceRanking to determine which configuration > listener gets notified first. If you can arrange that your listener is > called after DS, the configuration event is processed synchronously by DS. > > hope this helps > david jencks > > > >> On Jan 9, 2017, at 9:01 AM, Tom Quarendon >> <tom.quaren...@worldprogramming.com> wrote: >> >> I'm trying to use the CM_UPDATED and CM_DELETED config admin events in a >> test harness to ensure that a configuration change has been actioned before >> the test case gets run, but I'm unclear when exactly these get called. >> >> The OSGi specification doesn't seem very enlightening. "An event is fired >> when a call to Configuration.update(Dictionary) successfully changes a >> configuration". >> Configuration.update is documented as being actioned asynchronously. >> >> For example, I have a component that has a configurationPolicy of REQUIRED. >> In my test harness, in a tear down method (junit @After), I invoke a >> Configuration.delete method, then wait until the CM_DELETED event is fired. >> Am I guaranteed that the component has been deactivated by the time the >> CM_DELETED event gets fired? >> That's just an example. For UPDATED, if you have a configurationPolicy of >> REQUIRED, updating the configuration results in a deactivation and >> reactivation of the component, and consequent deactivation and reactivation >> of anything that has a required reference to it. Does the CM_UPDATED only >> occur after all that has happened? >> >> Annecdotally I do appear to see components being deactivated before the >> CM_DELETED event gets called for example. However, what I'm trying to do is >> solve test case unreliability that we are getting that we believe are caused >> by background "rewiring" still occurring when the test is then run, I want >> to be sure. >> >> What I'd *really* like is a guaranteed way of saying "come back to me when >> there's no further wiring to be done, your queue of outstanding >> configuration changes is empty". Then I know that I can put one of those in >> my test setup and I know that I've got a stable environment in which to run >> the test. At the moment, what we appear to see is that there is still >> reconfiguration going on in the background when tests start. >> >> Thanks. > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
