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: SLING-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

        

Reply via email to