在 Impala 和 OSGi 之间进行选择
我一直在研究我公司软件的 OSGi，但最近有人建议我看看 Impala。根据其网页，Impala 是“基于 Java 的 Web 应用程序的动态模块框架” ，基于Spring框架。”
一目了然，看看这篇关于差异，我看到的关键差异是 Impala 比 OSGi 更简单，不管理第三方组件的版本控制，并且使用/了解程度要低得多（我在 Stack Overflow 上没有看到任何关于它的问题）。
我想知道那些对 Impala 和 OSGi 有直接经验的人（即那些比阅读博客文章和在线文档更深入研究它的人）是否对两者之间的实际差异有更多的见解，和/或关于什么类型的建议每个项目都可能或多或少适合。
编辑：包含 Springsource Slices 进行比较，尽管它仍然是一个早期原型。乍一看，它似乎只能在 DM Server 中工作。
I've been investigating OSGi for my company's software, but have recently been recommended to take a look at Impala. According to its web page, Impala is "a dynamic module framework for Java-based web applications, based on the Spring Framework."
At a glance, and looking at this blog post about the differences, the key differences I can see are that Impala is simpler than OSGi, does not manage versioning of third party components, and is far less widely used/known (I do not see a single question about it on Stack Overflow).
I wonder whether people who have direct experience with Impala and OSGi (i.e. those who have investigated it more deeply than reading blog posts and online docs), have any more insights into the practical differences between the two, and/or suggestions about what types of projects each one may be more or less suitable for.
Edit: It may also be interesting to include Springsource Slices into the comparison, although it is as yet an early prototype. At a glance, it appears to only work in DM Server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当涉及到模块之间的受控共享时，Impala 的模块化方法非常薄弱。问题是 Impala 仍然遵循旧的 J2EE 风格的分层方法来进行类加载。
任何人都可以编写一个模块系统来限制跨模块的类的可见性。困难的部分是如何重新引入模块之间的依赖关系，以便一个模块中的特定类和接口可以被另一个模块看到。在 OSGi 中，我们通过导出和导入包来做到这一点，因此我们有一个非分层的依赖关系图。
在 Impala 中，如果您想查看另一个模块中的类，那么您的模块必须是该模块的子模块或后代模块。也就是说，模块只能看到它们自己的类和它们祖先的类。现在，如果您想与同级模块共享一些类（例如，您都使用的库），那么您必须将该库移到共享祖先的类路径中。在最坏的情况下，您必须将其直接移至根模块。现在，无论其他模块是否想要，该库都对所有其他模块可见！事实上，如果另一个模块想要使用该库的不同版本，他们将被阻止这样做。
如果您只是在每个使用该库的地方都有该库的副本，那么使用该库的模块就无法相互通信。当他们尝试在彼此之间传递对象时，他们将得到 ClassCastExceptions。
如果两个 Web 应用程序需要使用相同的库，J2EE 中也会存在类似的问题。通常，J2EE 开发人员只需复制该库，但这会创建无法相互通信的“筒仓”应用程序。这根本不是构建模块化软件的方法。
史蒂文的观点似乎也很中肯。据我所知，除了 Impala 的作者之外，没有人在使用它。
Impala's approach to modularity is very weak when it comes to controlled sharing between modules. The problem is that Impala still follows the old J2EE-style hierarchical approach to classloading.
Anybody can write a module system that restricts visibility of classes across modules. The difficult part is how you reintroduce dependencies between modules such that specific classes and interfaces from one module can be seen by another module. In OSGi we do this by exporting and importing packages, so we have a non-hierarchical dependency graph.
In Impala, if you want to see the classes in another module, then your module must be a child or descendant of that module. That is, modules can only see their own classes and those of their ancestors. Now if you want to share some classes with your sibling module (e.g. a library that you both use) then you must move that library up into the classpath of your shared ancestor. In the worst case you have to move it right up to the root module. Now the library is visible to ALL other modules whether they want it or not! Indeed, if another module wanted to use a different version of the library they would be prevented from doing so.
If you simply have a copy of the library in each place where it is used, then you make it impossible for the modules using that library to communicate with each other. They will get ClassCastExceptions when they try to pass objects between each other.
A similar problem is inherent in J2EE if two web applications need to use the same library. Typically J2EE developers just copy the library, but this creates "silo" applications that cannot communicate with each other. It is simply not the way to build modular software.
Steven's points also seem pertinent. As far as I can tell, nobody is using Impala aside from its author.
在我眼里，没有可比性。 OSGi 是一个已经存在 10 年的成熟框架，是当今大多数 Java 容器的实现基础。 OSGi 的采用率越来越高，有书籍可供参考，是的，人们在 Stack Overflow 上谈论它！
Impala 甚至还没有发布稳定版本，并且似乎是一个 1 人项目，尽管他现在正在寻求更多的开发人员。
所以，这取决于你的标准。如果您出于兴趣而研究技术，那么我认为使用 Impala 编写内容没有任何问题。如果您希望将公司未来的产品建立在它的基础上，那么我认为这将是职业疏忽。
In my eyes, there is no comparison. OSGi is a mature framework that's been around for 10 years and is the basis for the implementation of most of today's Java containers. OSGi has growing adoption, there are books available and, yes, people talk about it on Stack Overflow!
Impala hasn't even hit a stable release and appears to be a 1-man project, though he is asking for additional developers now.
So, it depends on your criteria. If you are investigating technology out of interest, then I don't see any issue writing stuff with Impala. If you are looking to base your company's future products on it, then I think that would be professionally negligent.