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
