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.
