Setting config properties with JMX bean happens asynchronously?

[to...@quarendon.net]

For test purposes we have a small java program that automatically deploys our
built bundles into a Karaf container as part of the build and test process.
However, the deployment process is unreliable.

Basically what we do is connect to the main Karaf container and create a new
instance. Then connect to that instance, and set the mvn url search repositories
to the repository into which we deploy the build artifacts and then do a feature
install. We do this all through the JMX interface.

The feature install often fails though, claiming:

Error resolving artifact <our bundle>: Could not transfer artifact <our bundle>
from/to apache (http://repository.apache.org/content/groups/snapshots-group/)

What's odd about this message is that we've just changed the mvn url search path
(org.ops4j.pax.url.mvn.repositories property in the org.ops4j.pax.url.mvn
configuration pid) so that it doesn't even include that repository. So why is it
looking there?

Looking at the implementation of the config JMX bean it just calls the OSGi
method Configuration.update. The actual config update though happens
asynchronously on another thread (so says the documentation for
Configuration.update).
It is possible to install a configuration change listener in OSGi that can
listen for completion of a configuration change to a certain pid, though I don't
know how you tell it was YOUR change, rather than a change that someone else has
made, but it's possible that would improve the situation.

This makes life very awkward, and you would appear to have to reply on a fragile
"sleep" in the client to give the configuration changes time to propagate before
you continue, or having made the config changes, stop the instance and restart
it again (I *think* that would work, I *think* that the configuration changes
are persisted by Karaf synchronously).

Other than making the config changes in the parent instance so that they are
inherited by the child instance, I'm not aware of any other way to make the
configuration changes in this kind of scenario.

Is this a known issue? Or is this as designed?

Thanks.