我一直在为我公司的软件调查OSGi,但最近建议我们去看看Impala.根据其网页,Impala是"基于Spring框架的基于Java的Web应用程序的动态模块框架".
一目了然,看看这篇关于差异的博客文章,我可以看到的关键差异是Impala比OSGi简单,不管理第三方组件的版本化,并且使用/知道的广泛使用(我看不到)关于Stack Overflow的一个问题.
我想知道那些对Impala和OSGi有直接经验的人(即那些比阅读博客文章和在线文档更深入地调查过的人)对于两者之间的实际差异有更深入的了解,和/或关于什么类型的每个项目可能或多或少都适合.
编辑:将Springsource Slices包含在比较中可能也很有趣,尽管它还是早期的原型.一目了然,它似乎只适用于DM Server.
Nei*_*ett 10
在模块之间进行受控共享时,Impala的模块化方法非常薄弱.问题是Impala仍然遵循旧的J2EE风格的分层方法来进行类加载.
任何人都可以编写一个模块系统来限制跨模块的类的可见性.困难的部分是如何重新引入模块之间的依赖关系,以便另一个模块可以看到来自一个模块的特定类和接口.在OSGi中,我们通过导出和导入包来实现这一点,因此我们有一个非层次的依赖图.
在Impala中,如果要查看其他模块中的类,则模块必须是该模块的子级或后代.也就是说,模块只能看到自己的类和它们的祖先类.现在,如果您想与兄弟模块共享一些类(例如您使用的库),那么您必须将该库移动到共享祖先的类路径中.在最坏的情况下,您必须将其移动到根模块.现在,所有其他模块都可以看到该库是否需要它们!实际上,如果另一个模块想要使用不同版本的库,则会阻止它们这样做.
如果您只是在每个使用它的地方都有一个库的副本,那么您就无法使用该库的模块相互通信.当他们尝试在彼此之间传递对象时,他们将获得ClassCastExceptions.
如果两个Web应用程序需要使用相同的库,那么J2EE中就会存在类似的问题.通常,J2EE开发人员只是复制库,但这会创建无法相互通信的"孤岛"应用程序.它根本不是构建模块化软件的方法.
史蒂文的观点似乎也很恰当.据我所知,除了作者之外,没有人使用Impala.
在我看来,没有比较.OSGi是一个成熟的框架,已经存在了10年,是实现当今大多数Java容器的基础.OSGi的应用越来越多,有可用的书籍,是的,人们在Stack Overflow上谈论它!
Impala甚至没有达到稳定版本,似乎是一个单人项目,尽管他现在要求其他开发人员.
所以,这取决于你的标准.如果您正在调查技术的兴趣,那么我没有看到任何与Impala编写内容的问题.如果您希望将公司的未来产品建立在其上,那么我认为这将是专业疏忽.
| 归档时间： |
|
| 查看次数： |
1005 次 |
| 最近记录： |