Jeff McAffer

Of course we are biased... OSGi has a pretty bright future IMHO. We are seeing strong adoption in the server world, its all over in Eclipse-land and there is renewed interest in its original domain of residential gateways, settop boxes, .. (i.e., embedded). Many enterprises are basing their architectures on OSGi. will it take over the world? What will happen with Jigsaw? Will it branch out into other languages? Who knows. I certainly believe that the technology and approach are sound.

I don't know of any books that cover that topic in detail.

This is a copyrighted commercial book published by Addison Wesley and available in standard bookstores.

Please let us know if you can find a free e-book. It means that someone is pirating our hard work...

For people interested in the OSGi and Equinox book (http://equinoxosgi.org), I thought I'd let you know that some of the content is available for free. See http://equinoxosgi.org/2010/03/two-sample-chapters-available/

The book should be a very good guide as it starts with nothing and incrementally builds up a quite sophisticated client server system touching on OSGi technologies and best practices along the way.

Chapter 19 is in the OSGi and Equinox book. See http://equinoxosgi.org.

The OSGi specs are available from http://www.osgi.org/Specifications/HomePage. you are likely looking for the Enterprise specifications.

There is some information on modularity best practices, how to debug and address classloading problems, ... All things that come up while migrating existing systems. However, for the most part we are focused on OSGi concepts and how to use them. Explicit coverage of techniques for migrating to OSGi is a great topic but would not fit in the available space.

D'oh! I forgot to mention that Jetty is part of the Eclipse space as well. It does not use OSGi explicitly but they produce bundles that run in an OSGi system so you can embed Jetty in your OSGi app (and vice versa).

Not sure the exact question here but do suggest that you look at Chapter 19 for details on how to setup OSGi to run in a WAR. Using this approach you do not craft web.xml files but rather run OSGi inside a WAR and then contribute servlets and JSPs via bundles and services.

If you are looking for a more classical WAR deployment approach but with using OSGi, then take a look at OSGi RFC66 (web container) and some of the things coming out of the Jetty project at Eclipse.

The benefit possibilities are many and varied. Anything from dynamic updating, easier configurability, faster deployment, lighterweight development, ecosystem development, dev team decoupling, ... Try thinking of "how would modularity help" and then think of OSGi as a way of implementing that.

The question is more "are there any payware app servers that do NOT use OSGi". Here is a list of those that I know that DO.
- Websphere
- Glassfish
- Spring dm Server
- SAP Netweaver (moving)
- JBoss (building their own OSGi but that story seems to be evolving)
- Oracle (I can never keep track due to acquisitions but they definitely have OSGi based server offerings)

So this is pretty safe ground for enterprise infrastructure.

If you are using Eclipse PDE to do your development then there are a whole host of tools available to generate and validate your dependencies. These should dramatically reduce the number of CNF exceptions. The book outlines a number of workflows in this area.

Karthik Shiraly wrote:
About making OSGi a JavaSE and JavaEE standard:
So are there any initiatives by OSGi backers to promote OSGi into an "official" Java API, and do you think it's a good idea to do so?

OSGi actually is already standardized at the JCP in the SE and ME spaces (JSRs 291 and 232 respectively). It is a little hard to tell what will happen with the direction of Java past the next releases in SE and EE space. Within OSGi proper there is quite a bit of effort to standardize in the EE space. The Enterprise Expert Group is focused very much on these topics. Eclipse (and in particular the Eclipse Runtime initiative http://eclipse.org/eclipsert) are moving strongly as well. We host the JPA2 reference implementation (EclipseLink), the OSGi Blueprint Services reference implementation (Virgo, formerly Spring dm Server) and various other standard implementations. Whether or not these make it into JSRs and in the JEE distro is AFAICT not known or an explicit goal.

Karthik Shiraly wrote:
About OSGi integration best practices:
Every example I've seen on OSGi involves a call to OSGi API for looking up a service.
...
Is there any framework / tool / approach to integrate OSGi in this manner? Does Equinox help in any way here?

Best practice for programming OSGi is to not program OSGi. As Paul says, if you find yourself calling OSGi all the time, you are likely doing something wrong. Dependency injection in various forms is the order of the day. Declarative Services, Blueprint, Guice/Peaberry, ...

Karthik Shiraly wrote:
About OSGi problems in Eclipse:
I use Eclipse Galileo but don't update regularly - only about once in 3 months. When I try to update certain components, I'm informed that the request can't be completed, because one component A requires a certain older/newer version of another component B. Attempts to update component B results in similar errors at another level. Is this indicative of some deployment problem even OSGi cannot solve? What should be done to avoid such problems in my OSGi-aware applications?

Just throwing thousands of components to the wind does not make for a solution. Producers need to coordinate the things they make available to their consumers. If you stick to the Galileo release repo for example then you should not have any problems updating. When you go broader there is less coordination in the version ranges and dependencies. Conflicts naturally occur. OSGi does not inherently cause or resolve these conflicts. The real value is that it makes them explicit so that a) they are discovered b) they can be processed and c) they can be avoided/fixed. Systems like Yoxos OnDemand (http://ondemand.yoxos.com/geteclipse/start) manage the vast arrays of bundles in a single repo and provide consumers with "slices" that are internally self-consistent. You are free to consume anything in the slice and be confident that the dependencies will resolve.

Karthik Shiraly wrote:
Why Equinox:
There are many competing OSGi container implementations. Where does Equinox score better? When would you not recommend Equinox? Does your book throw light on these topics?

We don't go into great detail about the various framework implementations. Everyone has different requirements and ways of looking at the framework characteristics. We do tend to see Equinox used in more industrial settings where performance, scalability and robustness are key drivers. WAS, Spring dm, SAP Netweaver, ... are all using Equinox. On the client you really can't beat Equinox and Eclipse RCP for user apps. On the embedded side it depends on how embedded you are talking. Concierge is tiny but also OSGi R3 (old) and not fully compliant. The Prosyst commercial implementations are small and performant in the embedded space. Equinox is larger but still used in significant embedded deployments. You have to weigh in the full spectrum of support, performance, development experience, ...

Bundle == plugin so Eclipse is 100% OSGi bundles.

As Paul says, making non-modular systems modular can be challenging. Most of the time it is not "OSGi" that is the problem but rather modularity itself. Being modular forces you to think about the boundaries between modules. For the most part OSGi is the messenger/enforcer, not the root cause.

Note also that Eclipse hosts a project called Orbit (http://eclipse.org/orbit) that has many third party libs "bundlized" and ready for use in OSGi-based systems. The Spring guys have something similar in their enterprise bundle repository.