[
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)
