[DS] Need to clarify behaviour for optional factory configuration arriving late

[bjhargrave]

Original bug ID: BZ#2778 From: @bosschaert Reported version: R6

[bjhargrave]

Comment author: @bosschaert

DS spec section 112.7.1.3 says:

"With a factory configuration matching a configuration PID, the factory configuration can provide zero or more Configuration objects which will result in a component configuration for each Configuration object or a single component configuration when zero matching Configuration objects are provided."

We need to clarify the behaviour when the configuration arrives after the 'single' component configuration was created for no matching configurations. Is that single component then destroyed or retained?

And what happens if the configuration disappears again?

[bjhargrave]

Comment author: David Jencks <djencks@us.ibm.com>

I think the behavior is described clearly. The "first" configuration appearing is described as a configuration change, and the "last" configuration being removed is also described as a configuration change. The behavior of configuration changes seems to me to be described completely.

I think the resulting behavior described by the current spec is:

no modified method >> any config change recycles the component

modified method >> (assume the component remains satisified at all points) "first" configuration appears >> unconfigured single component receives the new configuration properties "last" configuration disappears >> single configured component receives the new conponent properties which consist of all the remaining "single" pid configurations and component properties merged together.

With multiple pids there are a lot of cases to consider but when implementing this in felix ds I was confident every case was clearly specified by the spec.

[bjhargrave]

Comment author: @bjhargrave

I agree with David Jencks. This is already covered.

112.7.1 says "Changes include the creating, updating and deleting of Configuration objects matching the configuration PIDs."

So in the case of a factory configuration with optional configuration policy, going from zero to one and one to zero are both configuration changes.

112.7.1.3 says "If a Configuration object is then created which matches a configuration PID, this is a configuration change for the component configurations that are not using the created Configuration object. If a Configuration object is deleted which matches a configuration PID, this is a configuration change for the component configurations using the deleted Configurationobject."

This further restates the sentence in 112.7.1 and applies in all cases even for factory configurations. Don't forget that with multiple PID support, a component's properties can come from zero or one factory configuration and zero to N non-factory configurations. Any of these being created, updated or deleted is a configuration change for the component.

The spec covers this area quite well. But you do need to read the entire section of 112.7.1 including 112.7.1.4 which details the actions upon a configuration change.

[bjhargrave]

Comment author: @bosschaert

I disagree that the text covers it well.

(In reply to BJ Hargrave from comment BZ#2)

112.7.1.3 says "If a Configuration object is then created which matches a configuration PID, this is a configuration change for the component configurations that are not using the created Configuration object. If a Configuration object is deleted which matches a configuration PID, this is a configuration change for the component configurations using the deleted Configurationobject."

I can see this sentence, however the following paragraph starts with 'With a factory configuration...' which made me thing that the previous paragraph doesn't apply to factory configurations. I think that it would be beneficial to restate in the factory configuration paragraph what the behaviour is.

[bjhargrave]

Comment author: @bjhargrave

(In reply to David Bosschaert from comment BZ#3)

I disagree that the text covers it well.

I guess we disagree.

I can see this sentence, however the following paragraph starts with 'With a factory configuration...' which made me thing that the previous paragraph doesn't apply to factory configurations.

You are "overreading" that.

I think that it would be beneficial to restate in the factory configuration paragraph what the behaviour is.

Duplication is not our friend in the spec since duplicate information can get out of sync.

I could change the sentence 'With a factory configuration...' to be 'Also, with a factory configuration...' to make sure the reader is clear that the prior paragraph still applies.

[bjhargrave]

Comment author: @bosschaert

(In reply to BJ Hargrave from comment BZ#4)

I could change the sentence 'With a factory configuration...' to be 'Also, with a factory configuration...' to make sure the reader is clear that the prior paragraph still applies.

I would suggest to start the paragraph with 'Additionally, a factory configuration matching...'

Thanks for clarifying.

[bjhargrave]

Comment author: @bjhargrave

Fixed by https://www.osgi.org/members/gitweb/build.git/commit/27c7c230e25ad520219e977fcd1bbf8c95a35ae5