当缺少一个 configurationPid 时，OSGi DS 的组件属性的优先级如何？
How is the precedence of component properties for OSGi DS when one configurationPid is missing?
我有一个使用 Apache Felix configadmin、scr 和 fileinstall 的 OSGi 运行时。 Fileinstall 从目录安装配置。我的应用程序使用了许多具有不同 configurationPid 的 DS 组件。
当我添加新组件时，配置文件的数量不断增加，但很多文件只有一个或两个属性。我想摆脱先验知识为某个 属性 编辑哪个文件的必要性。因此，我想提供一个允许配置所有属性的配置文件的可能性。为此，我所有的组件现在都有一个优先级较低的“公共”pid，即
@Component(configurationPid = {"common", Component.NAME})
如果 fileinstall 的配置文件夹包含 common.cfg，如我所料，属性优先，即 componentName.cfg 优先于 common.cfg 中的那些优先于默认值。
但是，如果不存在 common.cfg，则不会使用 componentName.cfg 中的属性，仅应用默认值。但是没有公共文件应该没问题，因为专家仍然可以忽略这种可能性并保持配置独立。
示例 1:
common.cfg: myProp=a
componentName.cfg: myProp=b
-> 我的组件已按预期 b 激活
示例 2:
common.cfg: myProp=a
没有componentName.cfg
-> 我的组件按预期 a 激活
示例 3:
没有common.cfg
componentName.cfg: myProp=b
-> 我的组件默认激活为 myprop，这是我没有预料到的。
据我所知 112.6, point 2，规范并未明确提及如何处理缺少优先级较低的 PID 配置对象的情况。但是从配置管理员中检索到的配置始终优先于组件描述中的默认值（第 3 点）。
我对 configurationPid 工作原理的理解以及我对属性优先顺序的期望是否错误？观察到的行为是否符合 OSGi 规范？还是其中一个 Felix 包中的错误？
我不熟悉 felix-scr 的源代码，但我假设创建组件配置的相关部分在 ConfigurableComponentHolder.mergeProperties 中。实际配置是使用默认值创建的，然后配置管理员的配置以正确的顺序迭代，如果配置存在，则替换以前的属性，如预期的那样。我看不到第一个空配置会中断循环，因此它符合我的预期。
the spec does not mention explicitly how to treat cases where a configuration object for a lower precedence PID is missing.
如果缺少配置，则取决于配置策略。除非需要，否则忽略缺少的配置，这应该是这里的情况，因为您默认配置策略。
在我看来，示例 3 应该可以如您所愿地工作。我会与 Felix 开发人员核实，也许会提交错误报告。
我有一个使用 Apache Felix configadmin、scr 和 fileinstall 的 OSGi 运行时。 Fileinstall 从目录安装配置。我的应用程序使用了许多具有不同 configurationPid 的 DS 组件。
当我添加新组件时，配置文件的数量不断增加，但很多文件只有一个或两个属性。我想摆脱先验知识为某个 属性 编辑哪个文件的必要性。因此，我想提供一个允许配置所有属性的配置文件的可能性。为此，我所有的组件现在都有一个优先级较低的“公共”pid，即
@Component(configurationPid = {"common", Component.NAME})
如果 fileinstall 的配置文件夹包含 common.cfg，如我所料，属性优先，即 componentName.cfg 优先于 common.cfg 中的那些优先于默认值。
但是，如果不存在 common.cfg，则不会使用 componentName.cfg 中的属性，仅应用默认值。但是没有公共文件应该没问题，因为专家仍然可以忽略这种可能性并保持配置独立。
示例 1:
common.cfg: myProp=a
componentName.cfg: myProp=b
-> 我的组件已按预期 b 激活
示例 2:
common.cfg: myProp=a
没有componentName.cfg
-> 我的组件按预期 a 激活
示例 3:
没有common.cfg
componentName.cfg: myProp=b
-> 我的组件默认激活为 myprop，这是我没有预料到的。
据我所知 112.6, point 2，规范并未明确提及如何处理缺少优先级较低的 PID 配置对象的情况。但是从配置管理员中检索到的配置始终优先于组件描述中的默认值（第 3 点）。
我对 configurationPid 工作原理的理解以及我对属性优先顺序的期望是否错误？观察到的行为是否符合 OSGi 规范？还是其中一个 Felix 包中的错误？
我不熟悉 felix-scr 的源代码，但我假设创建组件配置的相关部分在 ConfigurableComponentHolder.mergeProperties 中。实际配置是使用默认值创建的，然后配置管理员的配置以正确的顺序迭代，如果配置存在，则替换以前的属性，如预期的那样。我看不到第一个空配置会中断循环，因此它符合我的预期。
the spec does not mention explicitly how to treat cases where a configuration object for a lower precedence PID is missing.
如果缺少配置，则取决于配置策略。除非需要，否则忽略缺少的配置，这应该是这里的情况，因为您默认配置策略。
在我看来，示例 3 应该可以如您所愿地工作。我会与 Felix 开发人员核实，也许会提交错误报告。