将EAR模块转换为OSGI包的正确方法 [英] correct way to turn EAR module into OSGI bundle

问题描述

有必要将EAR的一部分（即 - war）转换为OSGI捆绑包并保持它的互操作性。 Glassfish 3.0.1已经具有 osgi-web-container 模块，并且我成功部署了独立的OSGI战争。

但是在发生企业战争的情况下，我看起来有点困难。

1. 在未来的OSGI战争中，如何处理来自
   的EJB调用？是否足够
   用真正的JNDI
   查找替换 @EJB 注入？


2. 跨EAR共享的API和库
   如何？我可以拆分和
   重新排列它们，但是仍然我会
   至少有一个
   EAR和OSGI战争需要的jar。重复，使它
   作为OSGI捆绑包本身，并使其
   可用于某种方式，将其放置
   GF域的库路径？


3. 任何其他的想法，建议可以
   使混合工作？

解决方案

以下是一些可以尝试的方法：

• 无需替换 @EJB 通过JNDI查找。您的 @EJB 甚至可以在您的OSGi War（又名WAB）内继续工作。


• 您可以将共享库安装为一个包，那么它对于OSGi战争以及传统的EAR / WAR都是可见的。

我建议你在 GlassFish论坛。

There is a necessity to turn part of EAR (namely - war) into OSGI bundle and retain it's interoperability. Glassfish 3.0.1 already has osgi-web-container module and I succeeded to deploy standalone OSGI war.

But in case of of ex-enterprise war it looks a bit difficult to me.

1. What do I do with EJB calls from inside future OSGI war? Is it enough to replace @EJB injections with true JNDI lookups?
2. What about APIs and libraries shared across EAR? I could split and rearrange them, but still I will have at least one jar needed by both EAR and OSGI war. Duplicate, make it as OSGI-bundle itself and make it available to ear somehow, place it GF domain's library path?
3. Any other ideas, advices which could make that hybrid working?

解决方案

Here are a few things to try out:

• No need to replace @EJB by JNDI lookup. Your @EJB will continue to work even inside your OSGi War (aka WAB).
• You can install the shared library as a bundle, then it will be visible to both OSGi war as well as legacy EAR/WAR.

I suggest you follow up in GlassFish forum.

这篇关于将EAR模块转换为OSGI包的正确方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！