扩展器模式在最近几年变得很流行，甚至已经在OSGi标准（例如，蓝图服务和Web应用程序规范）中使用。 在处女座，我们从一开始就与扩展程序一起工作，但是尽管它们具有优势，但它们仍有一些明显的缺点。 由于OSGi联盟正在考虑在其他规范中使用扩展器，因此我同意记录一些问题。

第一个困难是知道扩展器何时完成了捆绑包的处理。 例如，一旦驱动了任何束激活器，包含蓝图XML文件的束将转换为ACTIVE状态。 但这还不是全部。 管理员对何时可以使用捆绑软件感兴趣，因此处女座中的管理代码会跟踪扩展程序的进度，并为代表捆绑软件的安装工件提供混合状态。 安装工件会一直处于STARTING状态，直到发布了应用程序上下文为止，此时该应用程序过渡到ACTIVE。 如果没有这样的附加基础架构，管理员将无法确定由扩展程序处理的捆绑包何时真正准备就绪。

那是成功的案例，但在错误案例中也有复杂之处。 第一个麻烦是，由于扩展程序在与安装捆绑软件的线程不同的线程中运行，因此，如果扩展程序抛出异常，则不会传播到安装捆绑软件的代码。 因此，安装程序需要以某种方式检查错误。 因此，处女座拥有检测此类错误并将其传播回启动捆绑软件部署的线程的基础架构：部署操作失败，并带有堆栈跟踪，指示出问题所在。

另一个错误并发症是处理扩展器的扩展器存在（可能不确定）延迟。 对于这种错误，Virgo会跟踪扩展程序处理的进度，并向事件日志发出警告（旨在引起管理员的注意），指出哪些处理过程已延迟以及在某些常见情况下（例如，当蓝图正在等待依赖项时） ，是什么导致延迟。

扩展程序需要能够查看包的生命周期事件，因此对于将框架进行分区的系统，必须将每个扩展程序安装到多个分区中。 另一方面，至关重要的是防止扩展程序的多个实例看到相同的捆绑事件，否则它们都将尝试扩展捆绑。

扩展器的另一个问题是需要使它们保持运行和健康，因为除了扩展器未处理的捆绑包外，几乎没有迹象表明扩展器发生故障或生病。 处女座小心确保其扩展器正确启动，其用于检测延迟的基础设施有助于诊断扩展器崩溃或疾病（这两种情况都是极为罕见的情况）。

将参数传递给扩展程序以影响其行为也存在一个问题。 通常，这是通过将扩展程序配置嵌入正在处理的束中或将包含片段的配置附加到扩展程序束中来完成的。 但是，由于扩展器不是由API驱动的，因此无法在调用时传递参数的常规方法。 本质上，扩展器模型意味着用于部署的编程模型仅限于BundleContext.installBundle。

通过在其他基础架构上进行大量投资，处女座设法合理地支持了Blueprint和Spring DM扩展器。 但是对于Web应用程序扩展器，Virgo无法使其足够强大，因此它直接从Virgo部署管道中驱动了基础Web组件，从而避免了上述问题。

我知道至少有另一个服务器运行时项目在扩展程序上遇到了类似的问题，因此处女座并不孤单。 在将安装程序与特定于资源的处理松散耦合，扩展程序模式的主要优势（但远非该模式唯一）与提供健壮的编程模型和可用的管理视图之间进行权衡取舍服务器运行时-如果没有扩展程序，这将更加直接。

参考： 扩展程序：模式还是反模式？ 从我们的JCG合作伙伴 Glyn Normington在Mind the Gap博客中获得。