部署 OSGi 包启动另一个

Question

我在 Felix 中部署了一个用于 Sling 的 OSGi 包 (BundleA)。此捆绑包加载初始 Sling 内容，然后通过激活器对此内容执行一些操作（设置权限和排序节点）。效果很好，我使用 Felix maven-bundle-plugin 构建它，并在激活器中放置了一个捆绑事件侦听器：

@Override
public void bundleChanged(BundleEvent event) {
  if (BundleEvent.STARTED == event.getType()) {
    logger.info("Bundle A has started");
    BundleContext context = event.getBundle().getBundleContext();
  }
}  

但我有另一个捆绑包 (BundleB)，在部署时会以某种方式触发 BundleA 的激活器。因此，代码再次执行，我不希望这样。

我没有找到任何关于“链接”捆绑包的文档。但我不熟悉 Felix/OSGi，所以我真的不知道要寻找什么。 BundleA 具有 BundleB 具有 Maven 依赖项，提供范围，因为它使用其中的一些常量。否则，我不知道有什么可以将他们两个联系起来。

任何关于什么可以触发另一个捆绑包的激活器的提示都会非常有助于理解它是如何工作的。如果需要，我可以发布更多代码/信息。谢谢

编辑：这是使用 CI 时引发问题的循环

1. 部署 BundleB（sling-core）：包含一个枚举类来存储常量
2. 部署 BundleA (sling-content)：加载 Sling 初始内容，并通过激活器使用 Jackrabbit API 自动设置权限和排序节点。此代码使用存储在 BundleA 中的枚举。
3. 重新部署 BundleB（sling-core），因为推送了一些更改
4. 问题：BundleA 也重新启动，然后重新进行权限和节点排序，这是我不想要的

Answer 1

用很短的话：

如果

启动一个Bundle (A)

• 设置为自动启动，并且bundle的启动级别低于framework的启动级别
• 另一个使用包 A 中的类的包 (B) 已启动

我猜你的包 B 使用了包 A 中的类，所以包 A 将在包 B 启动之前启动。

您可能希望将捆绑包 A 分成两个捆绑包。您可以创建一个只包含 Activator 的新 Bundle，因此当 Bundle B 启动时，这个新 Bundle 不会自动启动（因为这个新 Bundle 中没有使用任何类）。

如果你想有更深入的了解，我建议你应该阅读第 4.3 章以及从这个 OSGi Core 规范链接的其他一些章节。

顺便说一句：我从来没有在我的任何项目中使用延迟启动策略或未启动的捆绑包。如果您开始使用像声明式服务这样的组件模型，并通过 ConfigAdmin 根据配置创建组件实例化逻辑，您可能不会再遇到这样的问题。您实际上没有必要实施 Bundle Activators。

编辑

根据问题中的新信息：

随着 Bundle B 的更新和更新，Bundle A 被重新连接到 BundleB，然后再次启动。您应该考虑将捆绑 B 分成两个单独的捆绑。一部分更恒定（例如：B-API），另一部分则不是恒定的（B-IMPL）。 Bundle A 应该只使用 B-API，当 B-IMPL 更新时，您将不需要重新布线。

首先它似乎让你工作更多，但这是真正的逻辑分离。我们有很多只包含 1-2 个类文件的包，但它们很稳定，并且很长时间没有新版本。

Answer 2

我认为您不应该在捆绑包级别执行此操作。相反，您应该使用组件和服务。为此使用声明式服务 (DS)。

基本计划是：

1. Component1 执行您在 Sling 中所需的任何资源的设置。当这一切都完成后，它会发布一个服务……服务的类型并不重要，它可能只是一个没有方法的标记接口。

2. Component2 在该服务上有一个强制引用（使用@Reference 注释）。

现在，Component2 在服务可用之前不会激活。因此，在 Component2 的activate 方法中，您可以确定资源已经正确设置。

顺便说一句，如果您在 Component1 中执行的任务很耗时，则不应在该组件的 activate 方法中同步执行它们（或在 BundleActivator 的 start 方法中）事情！）。相反，您应该分拆一个线程并在那里执行它们。这避免了锁定 OSGi 事件系统和劫持属于启动器或其他包的线程。