felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Sedding (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3360) Bundle location is statically set for dynamically bound bundles
Date Wed, 14 Aug 2013 09:17:49 GMT

    [ https://issues.apache.org/jira/browse/FELIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13739441#comment-13739441

Julian Sedding commented on FELIX-3360:

Thanks for the fix, Felix. Thinking of "implicitly" binding a configuration rather than "dynamically"
binding it makes sense to me and makes it easier to understand the spec/contract.
> 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
>            Assignee: Felix Meschberger
>             Fix For: configadmin-1.8.0
>         Attachments: FELIX-3360.patch, 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
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message