我猜您更新后没有刷新,并且数学捆绑包导出了IMath吗/p>
如果更新软件包,则OSGi不会使旧的类加载器消失.该加载器只能通过垃圾回收来消除,即不再存在类引用.因此,当更新包1时,它将创建一个包1′,即新的类加载器.但是,您的包2仍绑定到包1类加载器.为了防止类路径异常,OSGi不会向捆绑软件2显示任何不兼容的服务.由于捆绑软件1’现在注册了IMath’服务,捆绑软件2由于查找捆绑软件1的IMath而无法再看到此服务,因此其类加载器仍绑定到捆绑软件1的IMath.所以这是工作情况：
+—-+ +—-+
| b1 |——-
+—-+ v +—-+ E exports package
___E___[IMath]___I__/ I imports package
现在我们进行更新：
/—-E–[IMath]—I–
+—-+ v +—-+
| b1 |
+—-+ | +—-+
| |
+———–+
+—-+
| b1’|——-
+—-+ v
___E___[IMath’]
刷新操作将查看所有捆绑软件,然后找出哪些捆绑软件已连接到“旧”捆绑软件(在本例中为b2).然后它将停止捆绑软件2,确保删除了它对b2的类加载器的所有引用,然后使用新的类加载器再次启动b2,以便可以解析为b1′.由于它是在刷新操作之前启动的,因此它将再次启动b2：
+—-+
+—-| b2 |
| +—-+
| |
+—-+ | |
| b1’|——-
+—-+ v |
_______[IMath’]______/
这通常会给人们带来以下问题：…..是什么什么不结合更新/刷新该如何处理.
在OSGi 1.0中,我们对这个边缘阶段不屑一顾(我想我们没有意识到它的存在).因此,在OSGi 2中,我们发现有些供应商“渴望”(将更新与刷新结合在一起),而有些则懒惰(有些根本不做任何事情).更深入地思考它,我们意识到如果我们渴望它,那么大的更新集将变得效率很低,因为刷新工作量很大.因此,我们假设更新将像这样进行：
>停止更新包
>更新包以进行更新
>刷新
>启动所有更新的捆绑包
这样,您可以最大程度地减少中断(更新的捆绑包仅停止/启动一次),并且捆绑包仅刷新一次.如果您查看bnd launcher,将会详细看到此模式(绑定更新会自动更改IDE中已更改的包).
现在,这种更新方式非常简单.但是,有些人喜欢生活在边缘并使用“优化”.首先,如果您有一个导出IMath的包3,就不会有此问题：
+—-+
| b1 |-I-
+—-+ |
| | +—-+
^ [IMath]-E-| b3 |
| | +—-+
+—-+ |
| b2 |-I-/
+—-+
在这个星座中,更新b1会很好,当b1’解析它找到IMath并将注册一个IMath服务时,恰好与b2的IMath类加载器(即b3)匹配.尽管这样做破坏性较小,但没有“逻辑”原因就增加了额外的捆绑包.就个人而言,我认为提供商(即b1)应导出其合同(IMath),因为它们与该合同紧密相关,而消费者通常享受向后兼容性.
文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91322 人正在系统学习中 相关资源：TranslationLoaderBundle:具有数据库翻译加载器的Symfony2捆绑软件
来源：沐雲閣主 荻生
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！