Ramping up on OSGi‬‏

Using Felix in one of the products I use and so I started needing to learn more about OSGi.

One really great resource to quickly get an overview of OSGi and why we care is from a youtube channel that has to really great and short videos called “Big EARS and OSGi – Part 1”, along with “Big EARS and OSGi – Part 2” on the following channel.

Part 1

Part 2

Also, two other great resources is the beginning of an IBM Redbook about OSGi (I only read the first chapter or so because the rest of the book starts diving into WebSphere…which I am not using).


While Felix is the product I am using, I have found that Spring DM has better documentation as to the Whys and Whats regarding OSGi. The reference documentation is an excellent resource:


As well as a great book reference:


Again, I only really needed to read the first chapter or two to get the overview of what OSGi was and how to make sense of the bundle manifest file that I was messing up.

When I started working with OSGi, it became simpler when relating Maven POM files to the way the manifest works in a sense. Like a Maven POM where I have to list the dependencies I used for that artifact/jar, as well as the versions that I need (or wildcarding to allow for many different types of versions). I could also place a scope on my POM file to determine dependencies between other POM files that relied on this jar. In the same way, OSGi manifest requires the definition of dependencies that will be externally provided, dependencies within the jar that will be exposed to other bundles, etc.

This blog talks about these features in explaining how to create an OSGi bundle:


The problems that I have run into initially trying to mess with OSGi is the concept that the bundles aren’t always self-contained and therefore when you need a 3rd party library, that bundle has to be deployed into the OSGi container (not necessarily bundled into your artifact like a war). OSGi is giving you the power to deploy multiple versions of a bundle/jar and allowing different bundles to select the version they want to use…this is why the wildcarding of your bundle manifest is critical…otherwise you can inadvertently create relationships with the wrong version of a jar.

Also, it is very important to understand what is said about the lifecycle of a bundle and how they become related to each other in the container, and how that effects undeploying them. This is talked about in the IBM Redbook:

Quoted from: http://www.redbooks.ibm.com/redbooks/SG247911/wwhelp/wwhimpl/js/html/wwhelp.htm (2.1.3 – Dynamism with OSGi)

All artifacts in OSGi are equipped with the support of dynamics in the form of defined life cycles (OSGi core specification on page 119). The life cycle of a bundle is much closer to that of a JEE application than that of a plain JAR file, which only exists on the class path. First of all, a bundle is installed into an OSGi runtime environment, which is called the OSGi framework, at a certain point in time. A bundle that is installed is known to the framework but otherwise useless. A bundle, whose dependencies can all be satisfied, next moves to the resolved state. Usually, a bundle will further transition to activestate either when any class from the bundle is loaded or when an external agent starts the bundle. At the end of its life, a bundle can be uninstalled from the framework again. However, when uninstalling a bundle, OSGi ensures that any packages, which the bundle provides to other still resolved or active bundles, remain available.

One last issue that I hit with some 3rd party tools is that some frameworks are just not OSGi friendly. One of the issues that can be found in older blogs, is related to TCCL (Thread Context ClassLoader) and the way it works differently in a JavaEE container as opposed to an OSGi container. It is discussed in these two threads:



Share and Enjoy