I have an OSGi Runtime using Apache Felix configadmin, scr and fileinstall. Fileinstall installs configurations from a directory. My application uses a number of DS components that all have a different configurationPid.
The number of configuration files increases continually when I add new components, but many files only have one or two properties. I want to get rid of the necessity of a-priori knowledge which file to edit for a certain property. Thus I'd like to offer the possibility to have a single configuration file which allows to configure all properties. To do that, all my components now have a "common" pid with lower precedence, i.e.
@Component(configurationPid = {"common", Component.NAME})
If the configuration folder for fileinstall contains a common.cfg, the properties take precedence as I'd expect, i.e. the properties from the componentName.cfg take precedence over those from common.cfg, which take precedence over defaults.
But, if there is no common.cfg present, then the properties from componentName.cfg are not used and only defaults apply. Having no common file however should be fine, since experts still can ignore that possibility and keep the configs separate.
Example 1:
common.cfg: myProp=a
componentName.cfg: myProp=b
-> My component is activated with b as expected
Example 2:
common.cfg: myProp=a
No componentName.cfg
-> My component is activated with a as expected
Example 3:
No common.cfg
componentName.cfg: myProp=b
-> My component is activated with the default for myprop, what I didn't expect.
As far as I unterstand 112.6, point 2, the spec does not mention explicitly how to treat cases where a configuration object for a lower precedence PID is missing. But the configurations retrieved from the config admin always have precedence over the default values from the component description (point 3).
Is my perception how the configurationPid works and my expectations how the properties should take precedence wrong? Does the observed behaviour comply to the OSGi spec? Or is it a bug in one of the Felix bundles?
I'm not familiar with the source code of felix-scr, but I assume the relevant piece to create the component configuration is in ConfigurableComponentHolder.mergeProperties. The actual config is created with the defaults, then the configurations from the config admin are iterated in correct order and replace previous properties if the configuration is present, as expected. I can't see that the first null configuration breaks the loop, thus it does what I'd expect.
the spec does not mention explicitly how to treat cases where a configuration object for a lower precedence PID is missing.
If a configuration is missing, it depends upon the configuration policy. Unless it is required, the missing configuration is ignored which should be the situation here since you default for the configuration policy.
It seems to me that Example 3 should work as you expect. I would check with the Felix devs and perhaps file a bug report.