what is wrong with the current way of developing/packaing/distributing a (large) java (web) application? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended 开发者_运维知识库discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

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.

---

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.