当前开发/打包/分发（大型）java（Web）应用程序的方式有什么问题？
有很多应用程序正在转向 osgi。互联网上有很多材料谈论使用 OSGi 的好处。但我没有看到当前使用非 OSGi（旧方式）构建/分发大型 java web 应用程序的方式存在的问题。有人可以
- 先概述一下开发、打包、分发大型 java web 应用程序的非 OSGi 和 OSGi 方式吗？
- 其次指出与非OSGi方式相关的问题？
- 第三，迁移到OSGi将如何解决这些问题。也许还可以给出具体的例子和参考资源。
There are lots of applications are moving towards osgi. And there are lots of material on the internet talk about benefits of using OSGi. But I fail to see the problems the current way of building/distributing a large java web application using non-OSGi(old way). Could someone
- first outline the non-OSGi and OSGi way of developing,packing,distributing a large java web application.
- Secondly point out the the problem associated with non-OSGi way?
- Thirdly, how moving to OSGi would solve these problems. Maybe also give concrete examples and reference resources.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“当前”方式是 WAR 文件，它们不共享。如果您有三个 Web 应用程序并且它们都使用 commons-lang，则必须部署同一 jar 文件的三个副本
（你可能是对的，这对大多数人来说并不是一个真正的问题）。
除此之外，OSGi 部署捆绑包，而不是应用程序。这允许应用程序的各个部分在运行时升级或激活。但不确定这对很多人来说是否重要。事实上，缺少“应用程序粒度”导致大量“可移动部分”以构成应用程序的所有捆绑包的形式可见。这让部署人员感到困惑。 OSGi 正在努力解决这个问题。
最后，在 OSGi 中，“容器”功能通常也是“应用程序”捆绑包集的一部分（而不是像 JBoss 这样与应用程序代码明显分离的黑盒）。以某种方式自带容器。非常灵活，但又让部署人员感到困惑。
The "current" way is WAR files, which are share-nothing. If you have three web applications and they all use commons-lang, you have to deploy three copies of the same jar file
(you might be right in that this is not a real problem for most people).
In addition to that, OSGi deploys bundles, not applications. This allows individual pieces of the application to be upgraded or activated at run-time. Not sure if that is important for many people, though. In fact, the missing "application granularity" leads to a great number of "movable parts" being visible in the form of all the bundles that make up an application. That confuses deployment people. OSGi is working on fixing that.
Finally, in OSGi the "container" functionality is also often part of the "application's" set of bundles (as opposed to a black box like JBoss that is clearly separate from application code). Bring your own container in a way. Very flexible, but again confusing for deployment people.