Hi Markus, Am 25.01.2012 um 14:19 schrieb Markus Joschko:
> Hi, > not sure whether this belongs to this list or to the felix mailing > list as I don't know whether the sling installer is responsible for > storing and applying configuration for components or felix is. > I give it a go here first ;-) > > > We have quite a large number of components with exhaustive > configurations. Most of these configurations do not change when a > bundle is upgraded, e.g. v. 1.0 -> v.1.1 > However the configurations are not reapplied to new component > "instances" . Instead I get errors like this: > > 25.01.2012 13:09:50.084 *ERROR* [CM Event Dispatcher (Fire > ConfigurationEvent: > pid=com.rbm.server.integration.internal.IntegrationDetailsImpl.4ca84ca4-3652-4bc6-b1a1-62b2af372c6e)] > org.apache.felix.scr Cannot use configuration > pid=com.rbm.server.integration.internal.IntegrationDetailsImpl.4ca84ca4-3652-4bc6-b1a1-62b2af372c6e > for bundle obr://com.rbm.core/-1327492547586 because it belongs to > bundle obr://com.rbm.core/-1326130284843 > > This is extremely inconvenient as I have to go through all components, > delete the configuration and recreate/reconfigure it which is quite a > pain on every bundle upgrade. Indeed. And even if you go through the Web Console to unbind and rebind the configuration, it is inconvenient. > I this because of the obr used to install the bundles from? I think I > have never seen this issue when simply using the sling:install mvn > target. The problem you might be facing here is, that the bundles do not get updated but uninstalled and installed again. This creates a new bundle location and thus causes the configuration to not be applicable any more. It looks like the configuration is actually not unbound when the bundle is uninstalled. This might be a Felix bug which you might want to file static your versions of the Declarative Services and Configuration Admin bundle versions in use. Regards Felix > > Any way to get around this behaviour? > > Thanks, > Markus
