当前开发/打包/分发（大型）java（web）应用程序的方法有什么问题？

有很多应用程序正朝着osgi的方向发展。互联网上有很多关于使用OSGi的好处的材料。但我看不到当前使用非OSGi（旧方法）构建/分发大型JavaWeb应用程序的方法存在的问题。有人可以吗

• 首先概述开发、打包和分发大型JavaWeb应用程序的非OSGi和OSGi方式
• 其次指出与非OSGi方式相关的问题
• 第三，迁移到OSGi将如何解决这些问题。也可以给出具体的例子和参考资料

当前的方式是WAR文件，这些文件不共享任何内容。如果您有三个web应用程序，并且它们都使用commons lang，那么您必须部署同一jar文件的三个副本 （你可能是对的，这对大多数人来说不是一个真正的问题）

除此之外，OSGi部署的是捆绑包，而不是应用程序。这允许在运行时升级或激活应用程序的各个部分。不过，我不确定这对很多人来说是否重要。事实上，缺少“应用程序粒度”导致大量“可移动部分”以组成应用程序的所有捆绑包的形式可见。这让人们感到困惑。OSGi正在努力解决这个问题

---

最后，在OSGi中，“容器”功能通常也是“应用程序”捆绑包集的一部分（而不是像JBoss这样的黑匣子，它显然与应用程序代码是分开的）。带上你自己的容器。非常灵活，但对部署人员来说又很混乱

+1个好问题。我还觉得OSGi是一个等待解决问题的解决方案（至少在大型JEE应用程序的环境中）@JB niset-OSGi已经为嵌入式市场服务了10年，Eclipse项目自迁移到OSGi以来从未有过更好的表现。坦率地说，JEE已经进行了许多完全不同的修改，仍然过于复杂和不一致。如果这是一个“等待问题的解决方案”，那么回答为什么所有的应用程序服务器都在OSGi上运行？我说“至少在大型JEE应用程序的环境中”。Eclipse基于可安装和可移动插件，其中OSGi非常有用。应用服务器需要一些模块化，以满足不同的客户配置文件。我的典型JEE应用程序每次进行最微小的修改时都必须通过大量的验收测试，而且仅凭一个可交付成果就很难部署。IMHO将其模块化，只会增加复杂性，不适合企业部署应用程序的方式。但那只是我的感觉。YMMV。@Michael Z:如果你想的话，错的是“依赖地狱”或“罐子地狱”。大型JEE应用程序经常使用（并且被卡住）过时的旧jar，无法用新版本取代它们，因为它们无法承受从（比如）1.2“跳”到2.0的代价。因此，他们一直依赖Buzzwordenterprisey 1.2，永远不会更新到（向后不兼容）2.0。这是“罐子地狱”。OSGi修复了jar地狱，还有其他问题。一个问题越好，它关闭得越快？投票赞成重新开放。