[
https://issues.apache.org/jira/browse/KARAF-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved KARAF-1243.
----------------------------------------
Resolution: Fixed
The issue should be fixed on trunk and 2.2.x
> Karaf JMX Config MBean behaves in unpredictable ways
> ----------------------------------------------------
>
> Key: KARAF-1243
> URL: https://issues.apache.org/jira/browse/KARAF-1243
> Project: Karaf
> Issue Type: Bug
> Components: karaf-config
> Affects Versions: 2.2.5
> Reporter: Jürgen Kindler
> Assignee: Christian Schneider
> Priority: Critical
> Fix For: 2.2.6, 3.0.0
>
> Attachments: KarafConfigMBeanTest.zip, karaf2.2.x-config.patch
>
>
> Although the API of the Karaf Config MBean looks like it offers synchronous
> calls, in reality
> this is not true. I ran into some issues with this, because I tried to
> install configurations
> for bundles to be picked up (see attached maven test case project to be used
> with a default running
> Karaf 2.2.5 container)
> It seems that the config bundle may need quite a long time to finish applying
> the configuration
> changes, but returns BEFORE this is finished in background.
> I have searched around, dug through code, but found no way to determine at
> which time I can
> safely assume that a configuration change is finished and I can continue with
> installing the bundle
> that may pick up this configuration (in some cases the default configuration
> is enough, but more
> often I want to override that...). So I finally ended up with polling for the
> configuration changes,
> but even that sometimes fails and I could loop infinitely and get no result
> (got an empty Map from proplist method).
> From the JavaDoc of the MBean I would - as said - expect that I do not have
> to do that, but could
> assume that after a create or propset call returns, the configuration is
> active. I would have been
> a bit happier, if the config MBean offered JMX events that notify about the
> completion of a
> configuration change, but after digging deeper it seems that even that would
> not be an optimal solution.
> From my understanding the underlying implementation is a mix of Karaf
> maintaining its own config
> files inside the etc folder plus updating data inside the OSGi ConfigAdmin
> Service.
> The good thing about the console commands is that they implement a strategy
> that really
> matches the idea of the OSGi ConfigAdmin service (the service always
> publishes complete configurations
> as Dictionary instances). So on the console the config commands maintain
> state between config:edit
> and config:update. Sending off config:update will publish all collected
> changes as one configuration
> instance.
> The API on the JMX level was more or less directly derived from the way the
> config console commands
> work, but tries to avoid maintaining state - so there's no equivalent to
> config:edit / config:update.
> Instead, propset, propdel and propappend immediately trigger propagation of
> simple changes to the
> configuration. So on JMX level the granularity is not sending of a new
> Dictionary instance, but
> reflects the operations to create such an instance. Instead of publishing one
> change a configuration
> containing 20 properties would trigger 20 changes.
> This will also cause multiple notifications for any "interested"
> configuration change listener ...
> resulting not only in more load, but also possibly in inconsistent
> configuration sub stages to cope
> with: Imagine a service requires two configuration parameters to work
> correctly. Instead of getting
> one configuration notification that contains the two parameters, it will get
> two notifications and thus will have to handle the case that the second
> parameter is missing (desperately hoping that sooner or later this second
> parameter will appear ...).
> Phew ':-) ... so I would suggest that this API should be changed:
> - guarantee that on return from an MBean method that changes a configuration,
> this configuration
> can be assumed to be active (so after creating a query call will return the
> equivalent created config).
> - if this appears to be impossible, the bean should at least provide JMX
> events a client can listen
> to in order to be notified when a configuration call is finished.
> - in order to play nicely inside the OSGi framework, it should be possible to
> create configurations
> by calling void create(String pid, Map<String, String> config)
> - propset / propappend / propdel should be deprecated or (better) directly
> removed. (They make sense
> on console, but not for JMX).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
