[ https://issues.apache.org/jira/browse/FELIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Sedding updated FELIX-3360: ---------------------------------- Attachment: FELIX-3360.patch > Bundle location is statically set for dynamically bound bundles > --------------------------------------------------------------- > > Key: FELIX-3360 > URL: https://issues.apache.org/jira/browse/FELIX-3360 > Project: Felix > Issue Type: Bug > Components: Configuration Admin > Affects Versions: configadmin-1.2.8 > Reporter: Julian Sedding > Attachments: FELIX-3360.patch > > > The method ConfigurationAdminImpl#getConfiguration(pid) dynamically sets the > configuration's bundle location if it is null. However, it uses > ConfigurationImpl#setStaticBundleLocation(location) in order to do so. This > should be changed to set the dynamic location. Attached is a proposed patch. > The issue I observed, that lead me to this bug, was as follows: > 1. Installed a number of factory configurations and the bundle (version > 1.0.0, bundle location: jcrinstall:/apps/sample/install/bundle-1.0.0.jar) > providing the service implementation (using SCR) via Sling's OSGi Installer > 2. Uninstalled the bundle. > 3. Installed the bundle (version 1.0.2, bundle location: > jcrinstall:/apps/sample/install/bundle-1.0.2.jar) > After this, the factory configurations were not bound to the bundle any > longer, because they were still bound to the no longer existing bundle > location jcrinstall:/apps/sample/install/bundle-1.0.0.jar. This basically > leaves stale configurations and a badly configured system. > While Sling's OSGi Installer handles updates without changing the bundle > location normally, the above scenario differs in that instead of an update, > there is an uninstall + re-install happening. The Configuration Admin Service > Specification 1.3 clearly states (in 104.4.1 Location Binding): "When this > dynamically bound bundle is subsequently uninstalled, the Configuration > object's bundle location must be set to null again so it can be bound again > later." > Note: in the patch I also changed the return type of > ConfigurationImpl#tryBindLocation() from boolean to void. Before, it always > returned true, so the return value is meaningless. I almost ended up using it > in an if statement because of the return type, which made me believe that it > returns true if the bundle location is set and false otherwise. -- 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