因此,我们需要必要的鲁棒性,允许在运行时删除和添加(重新部署)接口的提供者(B,C),而不需要重新部署接口的消费者(A),也不需要重新启动服务器.该解决方案将在Wildfly 8上运行,但只要在Wildfly 8上工作,可以使用或其他技术.
我们使用JBoss-OSGI和Weld-OSGI实现了一个POC,它满足了我们所有的要求,并为我们提供了一个很好的迁移路径.但是,在Wildfly 8 Alpha 3中,从默认分发中删除了JBoss-OSGI.这使我们认为我们应该探索更符合野猫背后的人的思想的替代品.
因此,问题是在Wildfly 8中,为满足我们的要求,模块间服务注入的OSGI替代方案是什么?
为了预算,简单性,性能管理和公司政策,我们不得不消除以下内容:
远程EJB的
2. Web服务
JSon / Rest
SCA
请注意,这不是关于OSGI的可行性或不同解决方案的评估或比较的辩论的请求.我只是寻找符合我们标准的任何解决方案,而不是基于OSGI.
大卫似乎在说的是服务本身的想法有缺陷 – 即你不需要他们! – 或者要求已经通过Java 6中引入的ServiceLoader API充分解决.
但是,已知ServiceLoader不适用于使用类加载器隔离的模块系统,包括OSGi和JBoss模块.这是因为ServiceLoader使用类路径扫描,并且在模块系统中没有“类路径”.在OSGi中,我们已经指定了一种适应ServiceLoader的方式(虽然它很幸运,但是需要字节码突出显示).也许JBoss模块也有一种方法来处理这个问题,但是我从文件的快速扫描中找不到任何东西.
无论如何,我在上面的评论中说,我对你的动机感到困惑.您明显可以从OSGi提供的服务模式中受益,而JBoss-OSGi仍然可以由Red Hat提供并支持…所以为什么不继续使用它?特别是如果WildFly没有任何明确的提供,您可以做任何事情.