[
https://issues.apache.org/jira/browse/FELIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13435062#comment-13435062
]
Felix Meschberger commented on FELIX-3360:
------------------------------------------
Reading over this issue again, I would think, that this is rather a problem of
the Declarative Services implementation, which does not let go of
configurations it assigns to bundles.
If you agree, I would reassign to the DS component as follows: Fix DS to make
sure configurations are "unassigned from bundles" upon bundle uninstallation.
> 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
