扩展剂：模式还是反模式？
第一個困難是知道擴(kuò)展器何時完成了捆綁包的處理。 例如，一旦驅(qū)動了任何束激活器，包含藍(lán)圖XML文件的束將轉(zhuǎn)換為ACTIVE狀態(tài)。 但這還不是全部。 管理員對何時可以使用捆綁軟件很感興趣，因此處女座中的管理代碼會跟蹤擴(kuò)展程序的進(jìn)度，并為代表捆綁軟件的安裝工件提供混合狀態(tài)。 安裝工件會一直處于STARTING狀態(tài)，直到發(fā)布了應(yīng)用程序上下文為止，此時該應(yīng)用程序過渡到ACTIVE。 如果沒有這樣的附加基礎(chǔ)架構(gòu)，管理員將無法確定由擴(kuò)展程序處理的捆綁包何時真正準(zhǔn)備就緒。
那是成功的案例，但在錯誤案例中也有復(fù)雜之處。 第一個復(fù)雜之處在于，由于擴(kuò)展程序在與安裝捆綁軟件的線程不同的線程中運(yùn)行，因此如果擴(kuò)展程序拋出異常，則不會傳播到安裝捆綁軟件的代碼。 因此，安裝程序需要以某種方式檢查錯誤。 因此，處女座擁有檢測此類錯誤并將其傳播回啟動捆綁軟件部署的線程的基礎(chǔ)架構(gòu)：部署操作失敗，并顯示堆棧跟蹤，指出出了什么問題。
另一個錯誤并發(fā)癥是處理擴(kuò)展器的擴(kuò)展器存在（可能不確定）延遲。 對于這種錯誤，Virgo會跟蹤擴(kuò)展程序處理的進(jìn)度，并向事件日志發(fā)出警告（旨在引起管理員的注意），指出哪些處理過程已延遲以及在某些常見情況下（例如，當(dāng)藍(lán)圖正在等待依賴項時） ，是什么導(dǎo)致延遲。
擴(kuò)展程序需要能夠查看包的生命周期事件，因此對于將框架進(jìn)行分區(qū)的系統(tǒng)，必須將每個擴(kuò)展程序安裝到多個分區(qū)中。 在另一方面，防止擴(kuò)展程序的多個實例看到相同的捆綁包事件至關(guān)重要，否則它們都將嘗試擴(kuò)展捆綁包。
擴(kuò)展器的另一個問題是需要使它們保持運(yùn)行和健康，因為除了擴(kuò)展器未處理的捆綁包外，幾乎沒有跡象表明擴(kuò)展器已關(guān)閉或生病。 處女座小心確保其擴(kuò)展器正確啟動，并且其用于檢測延遲的基礎(chǔ)結(jié)構(gòu)有助于診斷擴(kuò)展器崩潰或疾病（這兩種情況均極為罕見）。
將參數(shù)傳遞給擴(kuò)展程序以影響其行為也存在問題。 通常，這是通過將擴(kuò)展程序配置嵌入正在處理的包中或?qū)渲玫钠胃郊拥綌U(kuò)展程序包中來完成的。 但是，由于擴(kuò)展器不是由API驅(qū)動的，因此無法在調(diào)用時傳遞參數(shù)的常規(guī)方法。 本質(zhì)上，擴(kuò)展程序模型意味著用于部署的編程模型僅限于BundleContext.installBundle。
通過在其他基礎(chǔ)架構(gòu)上進(jìn)行大量投資，處女座設(shè)法合理地支持了Blueprint和Spring DM擴(kuò)展器。 但是對于Web應(yīng)用程序擴(kuò)展器，Virgo無法使其足夠強(qiáng)大，因此它直接從Virgo部署管道中驅(qū)動了基礎(chǔ)Web組件，從而避免了上述問題。
我知道至少有另一個服務(wù)器運(yùn)行時項目在擴(kuò)展器上遇到了類似的問題，因此處女座并不孤單。 在將安裝程序與特定于資源的處理松散耦合，擴(kuò)展程序模式的主要優(yōu)勢（但遠(yuǎn)非該模式唯一）與提供健壯的編程模型和可用的管理視圖之間進(jìn)行權(quán)衡取舍。服務(wù)器運(yùn)行時-如果沒有擴(kuò)展程序，這將更加直接。
參考： 擴(kuò)展程序：模式還是反模式？ 從我們的JCG合作伙伴 Glyn Normington在Mind the Gap博客中獲得。
翻譯自: https://www.javacodegeeks.com/2012/08/extenders-pattern-or-anti-pattern.html
總結(jié)
以上是生活随笔為你收集整理的扩展剂：模式还是反模式？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： （安卓刷赞）
- 下一篇： Web开发框架–第1部分：选项和标准