2

我有一个（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 支持的结构化配置的组件？

  • 与在 properties ...confiception 中定义 xml 配置文件的位置相反？并做我自己的解析。
4

1 回答 1

3

是的和不...

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

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

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

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

于 2013-11-15T12:38:12.467 回答