【问题标题】:Enforcing OSGi package imports强制 OSGi 包导入
【发布时间】:2016-09-15 13:36:51
【问题描述】:

tl;dr

我们有两组捆绑包。打电话给他们Group AGroup BGroup A 中的包必须仅从Group A 中的其他包导入包,无论Group B 中的某些包是否导出了可以满足依赖关系的包。 Group B 中的包可以解析来自任何包的包导入,无论它是在Group A 还是Group B

更长的解释

我的团队正试图找到一种方法来为使用 OSGi 构建的产品实施一种“安全模式”。本质上,我们有我们的核心产品,我们允许客户在上面安装他们自己的组件来扩展我们的功能。显然,这就是 OSGi 的用途。

但是,我们注意到,如果客户安装的捆绑包恰好导出了我们的一个核心捆绑包使用的包,那么核心捆绑包有可能会连接到第三方安装的东西。虽然我理解语义版本控制意味着这不是一个值得关注的主要原因,但我们注意到,如果/当一些第三方包被刷新时,我们的核心包的很大一部分会重新启动。

我们想要做的是确保我们核心产品中的捆绑包不会连接到第三方安装的任何捆绑包。我们使用捆绑包开始级别将我们的核心捆绑包设置为第三方捆绑包之前的开始级别。这让我们可以设置框架启动级别以排除我们核心之后的所有包,以防我们需要调试第三方代码的问题。但是,仅启动级别不足以防止包级别的依赖关系连接到我们的核心组件。

我能想到的唯一方法(我认为这不是一个好的解决方案,我们也没有计划实施)是在我们的核心产品发布后维护一个添加到运行时的所有第三方捆绑包的列表设置。然后,当框架关闭时,卸载此列表中的所有包(备份实际的包文件)。启动时,核心产品会启动并正确连接,然后我们会自动重新安装所有已安装的第三方捆绑包。这对我来说就像是一种非常脆弱、笨拙且完全错误的方式来实现我们想要的,但我想不出任何其他方式。所以我向 SO 社区寻求帮助!

【问题讨论】:

    标签: java dependencies osgi


    【解决方案1】:

    如果您已经围绕服务开发系统,那么有时最好的方法是启动另一个框架并在另一个框架中运行客户代码。如果您更倾向于经典 Java,那么这通常是太多的工作。

    那么有很多可能性:

    • Resolve Hooks - 使用这些钩子,您可以隐藏捆绑包,并且很可能完全按照您的意愿控制事物。
    • 安全性 - 使用安全管理器,您可以限制包的导入和导出
    • 属性 - 从核心中导出具有魔法属性的包,并仅在设置该属性时导入。
    • Weaving – 有一个编织钩子,可将不存在的包导入添加到每个非核心捆绑包。初始化核心,用不存在的包合成一个包并安装/解析它。

    很明显,Resolve Hooks 和 Weaving 都需要你的 bundle 尽早运行。如果您使用 Bndtools 启动器,那么有一种方法可以做到这一点。

    【讨论】:

    • Peter 我不同意为客户代码创建单独的框架工作量太大。在这种情况下,这似乎是正确的解决方案。正如您常说的,框架 == 应用程序。
    • 彼得,感谢您的大力响应。由于其他原因,我们一直在讨论在以后实施安全管理器,所以我认为这可能是我们运行的解决方案。我没有意识到它还能让我们以这种方式控制进口/出口,所以很高兴听到。
    猜你喜欢
    • 2011-03-06
    • 2017-04-07
    • 2023-04-08
    • 1970-01-01
    • 2018-12-28
    • 2011-11-25
    • 2012-10-11
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多