第一个困难是知道扩展器何时完成了捆绑包的处理。 例如，一旦驱动了任何束激活器，包含蓝图XML文件的束将转换为ACTIVE状态。 但这还不是全部。 管理员对何时可以使用捆绑软件很感兴趣，因此处女座中的管理代码会跟踪扩展程序的进度，并为代表捆绑软件的安装工件提供混合状态。 安装工件会一直处于STARTING状态，直到发布了应用程序上下文为止，此时该应用程序过渡到ACTIVE。 如果没有这样的附加基础架构，管理员将无法确定由扩展程序处理的捆绑包何时真正准备就绪。
那是成功的案例，但在错误案例中也有复杂之处。 第一个复杂之处在于，由于扩展程序在与安装捆绑软件的线程不同的线程中运行，因此如果扩展程序抛出异常，则不会传播到安装捆绑软件的代码。 因此，安装程序需要以某种方式检查错误。 因此，处女座拥有检测此类错误并将其传播回启动捆绑软件部署的线程的基础架构：部署操作失败，并显示堆栈跟踪，指出出了什么问题。
另一个错误并发症是处理扩展器的扩展器存在（可能不确定）延迟。 对于这种错误，Virgo会跟踪扩展程序处理的进度，并向事件日志发出警告（旨在引起管理员的注意），指出哪些处理过程已延迟以及在某些常见情况下（例如，当蓝图正在等待依赖项时） ，是什么导致延迟。
扩展程序需要能够查看包的生命周期事件，因此对于将框架进行分区的系统，必须将每个扩展程序安装到多个分区中。 在另一方面，防止扩展程序的多个实例看到相同的捆绑包事件至关重要，否则它们都将尝试扩展捆绑包。
扩展器的另一个问题是需要使它们保持运行和健康，因为除了扩展器未处理的捆绑包外，几乎没有迹象表明扩展器已关闭或生病。 处女座小心确保其扩展器正确启动，并且其用于检测延迟的基础结构有助于诊断扩展器崩溃或疾病（这两种情况均极为罕见）。
将参数传递给扩展程序以影响其行为也存在问题。 通常，这是通过将扩展程序配置嵌入正在处理的包中或将包含配置的片段附加到扩展程序包中来完成的。 但是，由于扩展器不是由API驱动的，因此无法在调用时传递参数的常规方法。 本质上，扩展程序模型意味着用于部署的编程模型仅限于BundleContext.installBundle。
通过在其他基础架构上进行大量投资，处女座设法合理地支持了Blueprint和Spring DM扩展器。 但是对于Web应用程序扩展器，Virgo无法使其足够强大，因此它直接从Virgo部署管道中驱动了基础Web组件，从而避免了上述问题。
我知道至少有另一个服务器运行时项目在扩展器上遇到了类似的问题，因此处女座并不孤单。 在将安装程序与特定于资源的处理松散耦合，扩展程序模式的主要优势（但远非该模式唯一）与提供健壮的编程模型和可用的管理视图之间进行权衡取舍。服务器运行时-如果没有扩展程序，这将更加直接。
参考： 扩展程序：模式还是反模式？ 从我们的JCG合作伙伴 Glyn Normington在Mind the Gap博客中获得。
翻译自: https://www.javacodegeeks.com/2012/08/extenders-pattern-or-anti-pattern.html
》)
