好企业网站,网站名称大全,wordpress多级菜单插件,大兴德艺网站建设扩展器模式在最近几年变得很流行#xff0c;甚至已经在OSGi标准#xff08;例如#xff0c;蓝图服务和Web应用程序规范#xff09;中使用。 在处女座#xff0c;我们从一开始就与扩展程序一起工作#xff0c;但是尽管它们具有优势#xff0c;但它们仍有一些明显的缺点。… 扩展器模式在最近几年变得很流行甚至已经在OSGi标准例如蓝图服务和Web应用程序规范中使用。 在处女座我们从一开始就与扩展程序一起工作但是尽管它们具有优势但它们仍有一些明显的缺点。 由于OSGi联盟正在考虑在其他规范中使用扩展器因此我同意记录一些问题。 第一个困难是知道扩展器何时完成了捆绑包的处理。 例如一旦驱动了任何束激活器包含蓝图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
