[jira] [Commented] (FELIX-1488) Configuration binding is broken

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

ASF GitHub Bot commented on FELIX-1488:
---------------------------------------

GitHub user drewbrokke opened a pull request:

    https://github.com/apache/felix/pull/113

    Fixes regression caused by FELIX-1488

    If one of the three calls inside of the `delete()` method throws an exception, the `isDeleted` field remains true, which causes some unexpected `IllegalStateException`s. 
    
    Before the field was introduced, whenever the `isDeleted()` method was called it would invoke `getPersistenceManager()`, which would then use the local persistence manager to actually check to see if the configuration had been removed from the persistence.
    
    Now the boolean field is being set before any persistence calls actually happen, which is a problem if any of the calls throw.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/drewbrokke/felix patch-1

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/felix/pull/113.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #113
    
----
commit 25260a6b84438722de67b688b1af8713dcabe13a
Author: Drew Brokke <dr...@liferay.com>
Date:   2017-07-19T19:38:27Z

    Fixes regression caused by FELIX-1488
    
    If one of the three calls inside of the `delete()` method throws an exception, the `isDeleted` field remains true, which causes some unexpected `IllegalStateException`s. 
    
    Before the field was introduced, whenever the `isDeleted()` method was called it would invoke `getPersistenceManager()`, which would then use the local persistence manager to actually check to see if the configuration had been removed from the persistence.
    
    Now the boolean field is being set before any persistence calls actually happen, which is a problem if any of the calls throw.

----


> Configuration binding is broken
> -------------------------------
>
>                 Key: FELIX-1488
>                 URL: https://issues.apache.org/jira/browse/FELIX-1488
>             Project: Felix
>          Issue Type: Bug
>          Components: Configuration Admin
>    Affects Versions: configadmin-1.0.10
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: configadmin-1.2.0
>
>
> Configuration can be statically or dynamically bound:
>  * A configuration is statically bound by explicitly calling the Configuration.setBundleLocation method or
>     by creating the configuration object with a non-null bundle location. Static binding must be persisted and
>     is only reset by explicitly calling the setBundleLocation with a null argument.
>  * A configuration may dynamically bound if the configuration has been created with a null bundle location and
>     the setBundleLocation has not been called (or called with a null argument). If such an unbound configuration
>     is provided to a ManagedService[Factory] it is dynamically bound to the service's bundle. Such bundle
>     binding is not persisted.
> The reason why dynamic binding need not be persisted is actually an implementation detail because we keep used configurations in an internal cache. Entries in the cache are only removed if the configuration is deleted or if the configuration admin service is stopped. In the first case, bundle binding is lost anyway. In the second case dynamic bundle bindings will be recreated on configuration admin service restart when the configurations are supplied to ManagedService[Factory] services again.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)