Question

我有一个（带有注释的）组件，它实现了一个简单的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需要结构化配置（列表列表，列表列表等等），我想知道是否有一种优雅的（*）方式通过类似的工作流配置组件的实例;也就是说，配置发现和实例化/部署仍然是集中的。

在我看来，配置服务规范管理地图 - 我将不得不推出我自己的配置服务＆amp; FileInstall能够使用xml / json / yaml支持的结构化配置呈现组件吗？

，而不是在属性... confiception中定义xml配置文件的位置？并做我自己的解析。

Answer 1

是，不......

OSGi配置管理服务处理抽象配置记录，这些记录基于平面地图（实际上是java.util.Dictionary，但它基本上是相同的事情）。配置管理员不知道有关底层物理存储的任何信息;它始终依赖其他人来调用ConfigurationAdmin服务上的方法，即getConfiguration，createFactoryConfiguration等。

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

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

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

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

1 个答案: