Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Thu, 9 Jun 2016 17:52:21 +0000 (UTC)
From: "David Jencks (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12974396.1464739948000.42159.1465494741056@Atlassian.JIRA>
In-Reply-To: <JIRA.12974396.1464739948000@Atlassian.JIRA>
References: <JIRA.12974396.1464739948000@Atlassian.JIRA> <JIRA.12974396.1464739948711@arcas>
Subject: [jira] [Commented] (FELIX-5270) [DS] Config race between update and
 delete
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 09 Jun 2016 17:52:23 -0000


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

David Jencks commented on FELIX-5270:
-------------------------------------

After discussion with the osgi cpeg expert group (cf https://osgi.org/members/bugzilla/show_bug.cgi?id=2909) we decided the spec will indicate that it takes no position on whether DS should set the bundle location.  Therefore the solution here is for felix ds not to ever set the bundle location, but continue to check that any existing bundle location is compatible with any component we consider supplying with the configuration.

> [DS] Config race between update and delete
> ------------------------------------------
>
>                 Key: FELIX-5270
>                 URL: https://issues.apache.org/jira/browse/FELIX-5270
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-2.0.2
>            Reporter: David Jencks
>            Assignee: David Jencks
>             Fix For: scr-2.0.4
>
>
> Thanks to Fabian Lange for reporting this problem and providing logging that shows what is going on.
> The first getConfiguration when the location is not set generates a LocationChanged event.  When we get such an event, we get the configuration to see what happened.
> DS: (either from query or initial CM_UPDATED event) calls getConfiguration, setting the bundle location and generating a CM_LOCATION_CHANGED event.
> User: delete configuration, setting the properties to null
> DS: receive CM_LOCATION_CHANGED, call getConfiguration (incidentally recreating the configuration) and get configuration with null properties and a location.  We then throw:
>                             if (configInfo.getProps() == null)
>                             {
>                                 throw new IllegalStateException("Existing Configuration with pid " + pid +
>                                         " has had its properties set to null and location changed.  We expected a delete event first.");
>                             }


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)