依赖注入 – 在Wildfly中模块间服务注入的OSGI的替代方法是什么
我们正在解开传统的单片EAR封装的
Java EE应用程序.我们(最复杂)的组件接线模式如下:组件A’需要“接口X,而组件B和C(… N)每个”提供“接口X.我们的要求是打包和部署A,B,C和X分开独立,以尽量减少停机时间并减少业务影响.
因此,我们需要必要的鲁棒性,允许在运行时删除和添加(重新部署)接口的提供者(B,C),而不需要重新部署接口的消费者(A),也不需要重新启动服务器.该解决方案将在Wildfly 8上运行,但只要在Wildfly 8上工作,可以使用或其他技术. 我们使用JBoss-OSGI和Weld-OSGI实现了一个POC,它满足了我们所有的要求,并为我们提供了一个很好的迁移路径.但是,在Wildfly 8 Alpha 3中,从默认分发中删除了JBoss-OSGI.这使我们认为我们应该探索更符合野猫背后的人的思想的替代品. 因此,问题是在Wildfly 8中,为满足我们的要求,模块间服务注入的OSGI替代方案是什么? 为了预算,简单性,性能管理和公司政策,我们不得不消除以下内容: 请注意,这不是关于OSGI的可行性或不同解决方案的评估或比较的辩论的请求.我只是寻找符合我们标准的任何解决方案,而不是基于OSGI.
由于您在询问WildFly背后的人的想法,我会将您引用以下邮件列表消息.它是由David Lloyd发布到Jigsaw开发列表中的,他是(我相信)WildFly所基于的JBoss模块的设计者.上下文是关于将服务模型引入到拼图:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-February/002161.html中的讨论
大卫似乎在说的是服务本身的想法有缺陷 – 即你不需要他们! – 或者要求已经通过Java 6中引入的ServiceLoader API充分解决. 但是,已知ServiceLoader不适用于使用类加载器隔离的模块系统,包括OSGi和JBoss模块.这是因为ServiceLoader使用类路径扫描,并且在模块系统中没有“类路径”.在OSGi中,我们已经指定了一种适应ServiceLoader的方式(虽然它很幸运,但是需要字节码突出显示).也许JBoss模块也有一种方法来处理这个问题,但是我从文件的快速扫描中找不到任何东西. 无论如何,我在上面的评论中说,我对你的动机感到困惑.您明显可以从OSGi提供的服务模式中受益,而JBoss-OSGi仍然可以由Red Hat提供并支持…所以为什么不继续使用它?特别是如果WildFly没有任何明确的提供,您可以做任何事情. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |