osgi - Eclipse 插件的延迟激活

Question

我想知道 Eclipse list 编辑器中的“加载其类之一时激活此插件”复选框有何用处。

我认为 Eclipse 总是使用“延迟初始化”方法。这个选项与插件的 BundleActivator 类有关系吗？初始化与激活有什么不同吗？

Here是一个类似的问题，但我不完全理解。

Answer 1

勾选该框会导致在 list 中设置以下 header :

Bundle-ActivationPolicy: lazy

我将从“纯粹的”OSGi 如何处理这个问题开始。如果bundle使用START_ACTIVATION_POLICY标志启动，则bundle进入STARTING状态，但不会调用激活器的start()方法，并且不会为bundle分配ClassLoader。 bundle 保持在 STARTING 状态，直到出于某种原因需要从 bundle 加载类。此时，将分配一个 ClassLoader，并实例化激活器(如果有)，并在加载请求的类之前调用​​其 start() 方法。

然而，Eclipse 在顶部添加了额外的语义。作为背景，Eclipse 总是尝试避免启动 bundle ，以保持最短的启动时间。默认情况下会启动一组非常小的核心 bundle (列表位于configuration/config.ini中)，其中一个称为p2“简单配置器”。 simpleconfigurator 会查找具有 Bundle-ActivationPolicy:lazy header 的 bundle ，并使用 START_ACTIVATION_POLICY 标志启动它们...因此这些 bundle 将按上述方式“延迟”启动。

重要的一点是，所有不包含 header 的其他 bundle 根本不会在 Eclipse 下启动。它们将保持在 RESOLVED 状态，它们的激活器将不会被调用，并且如果它们包含任何声明性服务组件，它们将不会被加载。这是因为声明式服务仅查看处于 ACTIVE 或 STARTING 状态的 bundle 。

因此，使用 header 的主要原因是我们想要编写一个包含需要在 Eclipse 下工作的声明性服务组件的包。

在其他环境中，不需要使用 header 。大多数普通的 OSGi 应用程序只是启动所有 bundle ，而不是尝试有选择地启动 bundle 的子集。请注意，这并不意味着 OSGi 应用程序不必担心延迟加载!声明性服务已经支持延迟加载，而不会弄乱捆绑类加载触发器。在我看来，Eclipse 犯了这个错误，并且给包生命周期增加了不必要的复杂性。然而，如果您在 Eclipse 中运行，那么您别无选择，只能理解并克服它的局限性。