Hi Tom, Let me start with saying that I'm not sure if the approach works with DS components but we use Amdatu Testing for our tests, that has an option for synchronous delivery of configurations [1]. This synchronous delivery mode bypasses ConfigAdmin and applies configuration changes directly to the ManagedService(Factory).
This has solved a lot of timing issues in tests for us ;) Another thing you could think about is waiting for the system to settle after a change to the environment. For example a configuration change will trigger services to become available or unavailable so it's possible to listen for all ServiceEvents after the configuration change and continue only if there was no ServiceEvent received in the last <<figure out a good timeout value>> ms. The second approach will take a bit longer as the update is still asynchronous and you'll always have the " timeout period". Regards, Bram 1: https://bitbucket.org/amdatu/amdatu-testing/src/bd5d65ffd556dfa2b7cd933c22ba36c87a5e9326/org.amdatu.testing.configurator/src/org/amdatu/testing/configurator/ServiceConfigurator.java?at=master&fileviewer=file-view-default#ServiceConfigurator.java-71 On Mon, Jan 9, 2017 at 8:47 PM 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 > >
