You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Julian Sedding (Created) (JIRA)" <ji...@apache.org> on 2012/02/21 17:08:34 UTC
[jira] [Created] (FELIX-3360) Bundle location is statically set for
dynamically bound bundles
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
[jira] [Updated] (FELIX-3360) Bundle location is statically set for
dynamically bound bundles
Posted by "Julian Sedding (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Sedding updated FELIX-3360:
----------------------------------
Attachment: (was: SLING-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
>
> 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
[jira] [Updated] (FELIX-3360) Bundle location is statically set for
dynamically bound bundles
Posted by "Julian Sedding (Updated) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (FELIX-3360) Bundle location is statically set
for dynamically bound bundles
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (FELIX-3360) Bundle location is statically set
for dynamically bound bundles
Posted by "Felix Meschberger (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (FELIX-3360) Bundle location is statically set for
dynamically bound bundles
Posted by "Julian Sedding (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Sedding updated FELIX-3360:
----------------------------------
Attachment: SLING-3360.patch
proposed 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: 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
[jira] [Commented] (FELIX-3360) Bundle location is statically set
for dynamically bound bundles
Posted by "Julian Sedding (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213502#comment-13213502 ]
Julian Sedding commented on FELIX-3360:
---------------------------------------
> 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.
My understanding is that the bundle location is indeed bound statically when a call to getConfiguration(String pid) *creates* the configuration. If the configuration *already exists* and is not yet bound (i.e. bundle location is null), it is then dynamically bound to the calling bundle, and unbound when this bundle gets uninstalled.
If you don't agree, I would be grateful, if you could point me to the relevant section(s) in the spec. The rest of the argument is based on the assumption that the above understanding is correct.
The scenario I observed while debugging the issue is, of course, a little more complex:
1. Sling's OSGi Installer (it's what the spec refers to as "management bundle") creates the configuration (IMO correctly) using getConfiguration(String pid, null). [0]
2. Somewhere (I didn't observe where exactly) an event of type ConfigurationEvent.CM_UPDATED is fired.
3.The Event is handled o.a.f.scr.impl.config.ConfigurationComponentRegistry#configurationEvent, which calls #getConfiguration and finally ConfigurationAdmin#getConfiguration(String pid).
In the issue description I was referring to the single argument call to getConfiguration in step three. I.e. a previously unbound Configuration object gets bound dynamically to the bundle, which retrieves the existing Configuration. In this case, I expect the Configuration to get unbound, when the bundle is uninstalled. See also [1].
The changes in the patch reflect this scenario. A new Configuration object, created via one of the single argument methods, should have its staticBundleLocation field already set upon construction. So the point where the dynamicBundleLocation gets set can never be reached (it is guarded by a null check for bundle location).
OSGi Enterprise Spec Release 4, Version 4.2, Configuration Admin Service Spec Version 1.3:
[0] 104.4.1 Location Binding: "These methods [the two argument versions of getConfiguration and createFactoryConfiguration] are intended for management bundles."
[1] 104.4.1 Location Binding: "A null location parameter may be used to create Configuration objects that are not bound. In this case, the objects become bound to a specific location the first time that they are used by a bundle. 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."
> 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