[
https://issues.apache.org/jira/browse/FELIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212730#comment-13212730
]
Felix Meschberger commented on FELIX-3360:
------------------------------------------
Sorry, I have to decline this request because it would violate the spec.
The spec states that a configuration retrieved with the single argument
getConfiguration(String pid) method must be statically bound to the calling
bundle. So everything works correctly.
In fact your use case of uninstalling and re-installing a bundle to update it
is not sensitive: You should really update the existing bundle. Not only will
you keep the configuration properly bound but also will you not loose any
potential bundle-private data (accessed through
BundleContext.getDataFile(String)).
With Configuration Admin spec 1.4 new definitions of the bundle location exist
and the Apache Felix SCR bundle (I assume you refer to that when you talk of
the getConfiguration(String pid) method) will be updated to actually use an
explicit bundle location of "?*" when accessing configuration to prevent this
kind of binding of unbound configuration.
> 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
