【发布时间】:2018-08-20 16:00:45
【问题描述】:
在 OSGi R6 中,我希望以编程方式验证用户提供的字符串配置属性以及服务工厂 PID,以根据声明它配置此 PID 的任何可配置@Component(或ManagedServiceFactory)所支持的内容,例如@Component(configurationPid=some.service.factory.pid, ...)。此外,我想以某种方式将有效的 String 属性转换为其适当的属性类型。翻阅 OSGi 纲要,似乎 Metatype Service 就是我要找的。p>
如果正确,请给出以下内容:
- 适用的组件使用组件属性类型来指定它们的配置
- 组件属性类型用
@ObjectClassDefinition注解 - 组件用
@Designate注解,映射到适用的@ObjectClassDefinition
这是将工厂 PID 映射到其ObjectClassDefinition 的最直接方式吗:
- 致电
BundleContext.getBundles()。对于每个捆绑包,请致电MetaTypeService.getMetaTypeInformation(Bundle)。 - 对于每个返回的
MetaTypeInformation调用MetaTypeInformation.getFactoryPids()并过滤我关心的工厂 PID。 - 对于适用的
MetaTypeInformation,调用MetaTypeInformation.getObjectClassDefinition(String, String)以获取ObjectClassDefinition,使用默认或特定区域设置。
(切向,上述每次执行似乎都很昂贵,因此缓存捆绑 ID,将它们映射到关联的工厂 PID,并以某种方式保持缓存最新似乎是合适的。)
或者,是否有一些其他的 OSGi 魔法可以通过服务工厂 PID 以编程方式查询,它返回的内容比上述过程更快地到达 ObjectClassDefinition?
更新 1
退后一步,我正在为我的每个可配置组件编写一个围绕 ConfigurationAdmin 的 CRUD 包装器。我试图避免createFoo,deleteFoo,updateFoo,createBar,...我的应用程序恰好适合 URI。所以我的工作方法是使用元类型服务,传入一个解析的 URI 查询 (Map<String, List<String>>),然后使用元类型服务来验证和重建这些值,循环回到 OP。 (另一方面,对我来说似乎不是一个漂亮的黑客攻击。)
另一种方法是使用aQute.bnd.annotations.metatype.Configurable.createConfigurable(Class, Map),我更喜欢它!直到我看到this bnd GitHub comment:
bnd 元类型注释在 bnd 3.2 中已弃用,并将在 bnd 4.0 中删除。这些注释被 OSGi 元类型注释替换。
所以如果它很快就会消失,我不想依赖那个包。我查看了 Felix 做了什么,不想使用他们等效的 Configurable 类。我对不同的方法都很感兴趣!
更新 2
为了进一步减少这种情况,我想在调用 ConfigurationAdmin.createFactoryConfig 之前验证可能由用户提供的键/值配置属性,以确保它们适用于某些配置 pid。也许这有点矫枉过正?
【问题讨论】:
标签: osgi