Eclipse插件的延迟激活答案

【问题标题】：Lazy activation of Eclipse pluginsEclipse插件的延迟激活
【发布时间】：2013-07-09 13:16:14
【问题描述】：

我想知道 Eclipse 清单编辑器中的“加载其中一个类时激活此插件”复选框有什么用处。

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

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

【问题讨论】：

【解决方案1】：

勾选该框会导致在清单中设置以下标头：

Bundle-ActivationPolicy: lazy

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

不过，Eclipse 在顶部添加了额外的语义。作为背景，Eclipse 总是尽量避免启动捆绑软件以保持其启动时间最短。默认情况下会启动一组非常小的核心捆绑包（列表位于 configuration/config.ini 中），其中一个称为 p2“simpleconfigurator”。 simpleconfigurator 查找具有 Bundle-ActivationPolicy:lazy 标头的包，并以 START_ACTIVATION_POLICY 标志启动它们...因此这些包将如上所述“延迟”启动。

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

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

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

【讨论】：

不错的答案。我仍然有几个问题。 1) 当我将产品配置中的插件设置为 autoStart:true 时，无论 Bundle-ActivationPolicy 标头如何，它都会启动？ 2) 无论如何开始是什么意思？你说“他们根本不会启动”。未启动的插件如何工作？
1) 是的。 2) 已启动意味着调用捆绑包的激活器并且实例化/管理 DS 组件。未启动的捆绑包（即 RESOLVED）仍然可以提供依赖项，例如导出可以由其他包加载的包。这对于被动库之类的东西很有用。
对了，你说的DS。它们都是菜单贡献、工作台部件贡献等扩展点吗？因为当我创建一个为透视图贡献视图的插件并且不设置它 Bundle-ActivationPolicy:lazy 时，视图仍然可见！？
不，DS 用于 OSGi 服务，您说的是在 plugin.xml 中声明的 Eclipse 扩展。他们不需要捆绑包处于活动状态，只需要 RESOLVED （顺便说一下，Eclipse 的另一个错误选择......）。
我一直认为 Eclipse 扩展是建立在 OSGi 服务之上的。