OSGi：通过编程决定是否可以启动捆绑包

上下文

我有一个基于OSGi的大型（Equinox3.9/EclipseRCP4.4）应用程序，还有几个“可选”包。这些可选捆绑包中的每一个都提供了可选的用户界面和一些额外的服务（通过SCR组件），这些服务只适用于我们的一部分客户

应用程序始终作为预打包安装分发（也就是说，我们不使用P2或任何其他自动配置机制）。直到最近，我们为每个需要一些可选捆绑包的客户构建了不同的预打包安装。可选捆绑包的数量正在增长，要构建的定制预打包安装的数量也在增长

因此，我们希望只构建一个安装包交付给所有客户，其中包含所有可选捆绑包，然后在运行时决定应启动哪些可选捆绑包。但这里有一个转折点：要启用的可选功能集只有在用户通过服务器身份验证后才知道。也就是说，一些最终用户可以访问多个帐户，每个帐户都可以访问一组不同的可选功能。因此，在用户登录之前，可选捆绑包必须保持不可用，然后只加载允许的可选捆绑包。由于这些可选捆绑包通过各种扩展器（Eclipse的插件注册表、SCR和蓝图）做出贡献，这意味着在确定它们确实有权启动之前，不允许可选捆绑包达到已解决状态。在用户登录和注销特定服务器帐户时，还必须能够加载和卸载这些可选捆绑包

潜在的解决方案和问题

我已经确定了一些潜在的解决方案，但每个方案都有未解决的问题。所以我只需要对以下任何一种情况的所有问题给出正确的肯定答案

拥有可选捆绑包需要一些“启用”功能。我认为这是最干净的方法。可选捆绑包将添加类似“Require-capability:com.acme.optionalfeatures；identifier=my-custom-feature-identifier”的内容。在运行时，该功能将一直无法解决，直到用户得到身份验证，因此扩展器将自动忽略该捆绑包。注册启用功能后，捆绑包将自动更改状态。太好了。但是这里有一些缺失的部分：a）我如何注册新的功能名称空间？b）我可以动态地更改捆绑包提供的功能吗？c） （如果（b）不可能）我可以动态注册具有新功能的新“资源”，如果可以，我如何注册

让可选捆绑包导入一些“启用”包。这是前一个场景的变体，可能比自定义功能命名空间更易于管理。。。这些“启用包”可以通过“Dynamicly创建的”包来实现。也就是说，一些管理器捆绑包将使用ByteArrayInputStream调用BundleContext#installBundle（String，InputStream），返回一个动态生成的捆绑包存档，其中包含一个Manifest.MF，该文件将导出相应的“启用包”。听起来很简单，但是工具链中的几个组件（IDE、PDE、P2、产品导出…）会抱怨这些必需的包不存在。为了避免这些问题，需要在将require包头安装到框架中时动态添加require包头。但是是否有任何机制允许尽早（即在将包安装到框架中之后）更改包的头？类编织在这里不适用

所有可选捆绑包都需要一个启用包（完全相同），该包确实存在。然后，当可选捆绑包尚未授权时，解析挂钩将从潜在的候选布线中筛选出导出该包的捆绑包。但是当用户登录或注销时，我以后如何请求重新考虑解决所有捆绑包？

排除的解决方案

以下解决方案已被排除在外：

• 将可选捆绑包放在不同的目录中，然后使用BundleContext#installBundle（…）启用这些捆绑包。尽管此解决方案在部署时确实可以工作，但它给开发带来了巨大的负担（因为捆绑包位于某个难以预测的文件夹中，相对于工作区、本地git配置、测试环境等等，因此无法正确构建要提供给#installBundle的位置）。打包过程也变得更加复杂，因为我们首先需要将这些可选包分开，然后更新几个Equinox/P2配置文件，以防止它们找到这些现在丢失的包

• 通过有条件地从其激活器中抛出异常，防止激活可选捆绑包。这根本不能解决我们的问题，因为仍然允许选项束达到已解决状态，因此能够通过中间扩展器做出贡献

• 使用P2在运行时安装新功能。这里的问题是，通过P2对bundle列表所做的更改1）本质上是持久的（这意味着可选功能将在下一次启动时自动重新启用），2）需要重新启动framwork才能正确完成

注意：对于这些额外的捆绑包实际上分发给不需要它们的用户这一事实，我们并不担心与“安全”相关的问题。我知道，用户可能很容易通过破解安装来强制推出一些可选捆绑包