使用 osgi 访问 bundle 内的公共属性文件答案

【问题标题】：access common property file inside bundle with osgi使用 osgi 访问 bundle 内的公共属性文件
【发布时间】：2012-05-25 05:32:41
【问题描述】：

我有一个带有多个捆绑包的 osgi 应用程序（在 felix 中）。一个包中有一些通用的属性文件，其余的包只需要使用它们即可。

我们使用 maven 和 spring osgi，属性文件位于以下资源中：

<path to bundle>/src/main/resources/
    common.properties
    engine.properties
    ...

Maven 通常在 bundle jar 中构建它们，因此它们应该位于应用程序类路径中，但 Spring 无法访问它们，这会失败：

<context:property-placeholder location="classpath:common.properties" />

（尝试过 classpath*: 和其他组合）

我读过this 和this

这真的是 osgi 意识形态的一些全球性问题，并且没有标准的方法让它发挥作用吗？只有像that 或<osgix:cmProperties...> 这样的黑客和变通方法？

之所以担心，是因为它使部署变得更加困难且容易出错：您不能像在普通应用程序中那样仅使用 mvn deploy 在 jar 中部署属性文件 - 您必须在每次发布时手动将它们复制到生产箱.

【问题讨论】：

【解决方案1】：

对于 OSGi，没有通用的应用程序类路径。尽管属性位于包含它们的包的类路径中，但它们不一定位于使用它们的包的类路径中。

这有点难看，但通常导出包含属性文件夹的“包”将使它们可以访问。在这种情况下，它看起来像'.'，这非常难看，但你可以将它们放在'properties'目录中（比如说），然后导出一个属性包。使用这些属性的捆绑包也需要导入属性包。

或者，使用包含包的类加载器来查找资源也可以，尽管我无法评论 Spring 配置的外观。

【讨论】：

但您可以将它们放在“属性”目录中（比如说），然后导出属性包... - 谢谢，没听说过这种方式，虽然将 prop 文件夹导出为 java 包，但似乎是另一个 hack）
我同意这感觉就像一个黑客。 :) 一种思考方式是模块化意味着 jars 不应该在其他 jars 的内部扎根，而不声明明确的依赖关系。包导出对类工作得很好，但对属性来说有点笨拙，也许那里的教训是，有比共享属性文件更简洁的通用配置技术；要么公开配置服务并且可以以更简洁的方式共享，要么使用配置管理。当然，其中任何一个的进入门槛都高于普通的旧属性文件。
我明白了，是的，osgi 将您提升到一个企业级别，以避免处理普通属性文件 =) 要么公开配置服务，并且可以以更简洁的方式共享，要么使用配置管理.其中任何一个的进入壁垒都更高.. - 恐怕不仅进入壁垒，而且当您通过另一个捆绑包中的某些配置服务引用您的属性值时，您还会获得性能开销，我的意思是 sm 类型的序列化/代理/反射开销。
我将其标记为答案，因为它似乎更合理的解决方法，但我个人更喜欢另一个：将 common 道具放在文件系统中并从 spring 引用为 file:./path/to/common-道具。

【解决方案2】：

读取所有捆绑包的公共属性的最佳方法是使用 spring DM 提供的概要服务。

【讨论】：

【解决方案3】：

我发现属性文件应该是“通用”的情况很少见。你不能分解属性文件的内容并将它们放在实际需要它们的包中。属性应按上下文分组并放置在需要该上下文的包中。

理论上类似于不使用常量类或接口，这被认为是一种反模式。

【讨论】：

考虑多个可以访问同一个数据库的包 - 您必须在每个包中硬编码相同的数据库属性？
对于这种特殊情况，使用持久性捆绑包和 JPA 可能会更干净、更容易。
如果您需要一个通用数据库，那么最好的方法是配置一个 DataSource 并将其作为 OSGi 服务发布。然后，您的用户捆绑包可以简单地引用服务，而不必了解数据库属性。见：liquid-reality.de/x/LYBk

【解决方案4】：

我最终使用的另一种选择 - 将属性文件放置到文件系统中，并从 spring（或其他代码）中将它们引用为 file:path/to/common.props。

【讨论】：