There was a recent post on theserverside regarding Spring's decision to move spring dm server to Eclipse. There were a lot of posts that I thought sounded like people do not really understand what OSGi is really for and what are its benefits outside of the embedded realm.
www.theserverside.com post:
http://www.theserverside.com/news/thread.tss?thread_id=59183
Here is what I wrote there:
The responses suggest that many people don't consider OSGi a trivial concept.
And at first it isn't, but after reading a bit about it, it actually makes a lot of sense.
The primary issue that enterprise (as opposed to embedded) OSGi tries to solve is the JVM class loading issues.
Secondly, it is the separation of concerns.
As far as the JVM class-loading issue is concerned, I'm sure everyone that has worked with Java to a degree has run into JVM classpath issues, whether its related to having the same package class names, or having multiple jars with slight version variations loaded into the JVM memory.
OSGi allows the developer to specify which exact packages should be loaded into the JVM and even allows multiple JARs with let's say different versions to be loaded at the same time.
However, when you import you are given the option to specify which version of the package that you want to import. This provides much more granularity than just specifying the versions of the JAR files themselves.
When you create a jar, it is good practice to specify the versions of all of the packages that you are exporting as well.
As far as the second issue (separation of concerns), OSGi makes you start thinking about your code in terms of modules. A module should do something very specific.
As an example, you may have one module that has a specific JDBC driver for your database. Another one that deals with DAO layer. Another module that deals with exposing your business logic via REST or SOAP.
Furthermore, a good practice is to split each of your modules into an all interface bundle and one that is all implementation. That way you can swap out your implementation at any time with another bundle at runtime, without compromising your contracts defined in the interface bundle.
As far as the complexity of dealing with the Manifest file, that isn't the case. You actually don't need to change your manifest file directly.
As Stuart mentioned, if you use maven, the felix's maven bundler plugin will help you to manage your relationships of the bundles and packages for you.
You still need to provide which packages you want to import and export.
And another great feature of OSGi is that it allows you to swap out a piece of your functionality without bringing down the server.
In conventional containers the entire web application has to be restarted. With OSGi, nothing is down and only a piece of your code is actually refreshed with newer code.
