使用 XML 配置服务 ..（而不是属性）

Question

我有一个 (bnd-annotated ) 组件，它实现了一个简单的 api 并将自己公开为一个服务

package com.mycompany.impl;
import com.mycompany.api.IFoo;

@Component(designateFactory=FooImpl.Configuration.class)
class FooImpl implements IFoo {

  interface Configuration {
    String foo();
    // ..
  }

  Configuration configuration;

  @Activate
  public void activate(Map properties) {
    configuration = Configurable.createConfigurable(Configuration.class, properties);
    // ..
  }

} 

它的配置是由 Felix FileInstall 从监视目录加载的，并且该服务由 Felix 配置服务实例化（至少，我认为这是发生的事情 - 我是 OSGi 的新手，请多多包涵）这个，与生成的 MetaType 描述符运行良好。

但是，就目前而言，FooImpl 需要结构化配置（列表列表、列表映射等），我想知道是否有一种优雅的 (*) 方法可以通过类似的工作流程来配置组件的实例；也就是说，配置发现和实例化/部署仍然是集中的。

在我看来，配置服务规范管理地图 - 我是否必须推出自己的配置服务和 FileInstall 才能呈现带有 xml/json/yaml 支持的结构化配置的组件？

• 相对于在属性中定义 xml 配置文件的位置 ...confiception ？并进行我自己的解析。

Answer 1

是，不是……

OSGi Configuration Admin 服务处理基于平面图的抽象配置记录（实际上是java.util.Dictionary，但本质上是一样的）。 Config Admin不对底层物理存储一无所知；它总是依赖其他人调用ConfigurationAdmin 服务上的方法，即getConfiguration、createFactoryConfiguration 等。

调用 Config Admin 的“其他人”通常称为“管理代理”。 Felix FileInstall 是一个非常简单的管理代理示例，它以 Java 属性格式读取文件。实际上 FileInstall 可能太简单了，我认为它不适合生产部署 - 但这是一个单独的讨论。

听起来您想编写自己的管理代理来读取 XML 文件并将它们提供给 Config Admin。这真的不是一项艰巨或艰巨的任务，你不应该害怕接受它。 Config Admin 的设计假设应用程序对配置数据存储有非常不同的要求，因此大多数应用程序必须编写自己的简单管理代理，这就是它没有定义自己的存储格式或位置的原因.

但是，一旦您的管理代理读取了配置数据，就必须将其作为地图/字典传递给 Config Admin，然后再将其作为地图传递给组件。因此，组件本身不会接收高度结构化的数据，例如树或嵌套地图。不过有一些灵活性：配置属性可以包含基于类型的列表；您还可以使用枚举值等。