Thanks - that's what I was starting to lean towards as well...
David
On 01/06/2012 13:03, Thomas Diesler wrote:
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