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

Evolution of Logging – Log4J to SLF4J to Logback

Logging has always been a very important part of development. One of the current trends is to utilize a framework called SLF4J which takes the place of what commons logging intended to do. SLF4J can be used directly for logging or it can be the wrapper that allows other implementations to be plugged in under the covers. This would allow developers to code logging logic against the SLF4J API and add log4j.jar or logback.jar into the classpath and it would use these logging implementations for generating the logging statements. The following is an example of the simplistic changes that have to be made in order to use SLF4J:

 import org.slf4j.Logger; import org.slf4j.LoggerFactory;
    private static Logger logger = LoggerFactory.getLogger(Entity.class);

As far as the implementation is concerned, Log4J has been used for quite a while but it’s codebase is stagnant if not dead. In the last 5 years, there has only been a maintenance update. Another new framework has emerged that has been created by the creator of Log4J and it is called Logback. Logback makes many improvements over Log4J and it also simplifies much of the configuration. One of the more powerful features that I will not be taking advantage of is coding the configuration files using Groovy and having the ability to build conditional logging files based on environments or hosts.

Logback also adds additional capabilities to add simplicity and performance to the normal String concatenation that occurs through logging, such as:

 logger.info("{} has logged in", userID);

Instead of writing this as:

 logger.info(userId + " has logged in");

One of the other nice features is that when an exception is thrown, logback will attempt to identify in the log which jar file contains the class mentioned in that line of the stacktrace. This provides benefits for troubleshooting runtime issues.

Many frameworks or third party applications use other logging frameworks such as commons logging or Log4J. SLF4J provides jar files which are bridges for routing logging requests to from these frameworks onto the SLF4J framework. With the inclusion of the two logback-classic.jar and logback-core.jar, logback becomes that implementation. I will be using logback as the underlining implementation moving forward, as well as providing jcl-over-slf4j.jar and log4j-over-slf4j.jar to bridge the requests through SLF4J.

Another important part of the framework to understand is how logback loads its configuration files. There are two different types of files that can be provided, a logback.xml and a logback-test.xml. So in a maven project, I can supply both of these configurations (one to be used during production and one to use during unit testing.

The following is a code snippet that explains how logback searches for configuration files:


Logback can be configured either programmatically or with a configuration script expressed in XML or Groovy format. By the way, existing log4j users can convert their log4j.properties files to logback.xml using our PropertiesTranslator web-application.

Let us begin by discussing the initialization steps that logback follows to try to configure itself:

  1. Logback tries to find a file called logback.groovy in the classpath.
  2. If no such file is found, logback tries to find a file called logback-test.xml in the classpath.
  3. If no such file is found, it checks for the file logback.xml in the classpath..
  4. If neither file is found, logback configures itself automatically using the BasicConfigurator which will cause logging output to be directed to the console.

The fourth and last step is meant to provide a default (but very basic) logging functionality in the absence of a configuration file.

If you would like to read more, I have included resource links.





Share and Enjoy