I'd say it depends on whether update is semantically equivalent to remove+add. It is feasiblethat a service goes DOWM when its config is removed, which would trigger a cascading service state change to DOWN. > Maybe I should get rid of this UPDATING_FLAG and an UPDATE operation > to the DMR API Yes, that would be the right thing to do IMO. cheers -thomas On 05/30/2012 07:59 PM, David Bosschaert wrote: > Before filing a pull request I would appreciate someone reviewing my > suggested changes for > https://issues.jboss.org/browse/AS7-4893 (ConfigAdmin configuration not > available after restart) > > My changes are in the following commit: > https://github.com/bosschaert/jboss-as/commit/bf221bc316c254401ee1b1c25d9... > > > In particular I'm a little unsure about the > ConfigurationRemove.UPDATING_FLAG that I introduced. > ConfigurationAdminServiceImpl.putConfiguration() first removes the old > configuration from the model and then adds the new one. The problem is > that the deletion in this case shouldn't really be sent to the > ConfigurationAdmin service as we aren't really deleting the config > object. The UPDATING_FLAG is used to indicate that notifications should > not be sent of this removal. I guess the mismatch is that OSGi > ConfigAdmin has an update() which replaces the old value where the DMR > API only supports REMOVE followed by ADD. > > Maybe I should get rid of this UPDATING_FLAG and an UPDATE operation to > the DMR API? Any ideas appreciated > > Cheers, > > David > _______________________________________________ > jboss-osgi-dev mailing list > jboss-osgi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-osgi-dev