Let’s play with OSGi, Spring and Maven, part 1

In programming every problem can be solved by adding another layer of abstraction

Today, I am going to write about my experiments with OSGi. Please, be aware that I do not know OSGi. Moreover, I am too lazy to learn it. But I know Spring and Maven quite well, so I will use them quite extensively.

I will try to implement following sample application

Sample application

We will have 5 bundles in total. Bundle is basic building block when working with OSGi applications. Please, read the OSGi documentation for more details.

We will have the Common bundle, which is quite simple passive bundle. It contains DataLoader and DataReceiver interfaces and Data object. This bundle does not provide any service, but every other bundle has compile-time dependency on it.

DAO bundle provides DataLoader service implementation. Please, imagine that there is some really cool data access logic.

UI bundle provides DataReciver service implementation. Again, we will pretend that there is something more sophisticated than printing to the console. To make the example more interesting, we will have two different implementations of the UI.

And in the middle of the application sits Service bundle that loads data from the DAO layer and propagates them to the UI layer.

Before diving into the code, I want to point out one interesting thing. If you look at the picture, you will see red and black arrows. Black arrows represent compile-time dependencies. Basically it means, that when I want to compile UI, Service and DAO, I have to have Common jar in the classpath. But I do not need to have there any other bundle. It means, that the bundles are really decoupled. They just do not need to know about each other. They are independent. Do you understand? That's the modularity we are looking for. The only thing the bundle needs to know is the interface of the service. Did I already mention that the bundles are independent? If not, I am saying it right know. They are independent.

The red arrows are run-time dependencies. That's what OSGi framework is for. It will find for us the implementations of the interfaces (services) and will connect them together.

DAO service

So lets dive to the code. We will start with the DAO service. OSGi uses MANIFEST.MF file for defining its meta-data. Since I am to lazy to write it, I will use Maven plugin to generate it for me.


As you can see, I am using Apache Felix plugin for Maven. It generates following MANIFEST.MF file for me.

Manifest-Version: 1.0
Export-Package: net.krecan.spring.osgi
Private-Package: net.krecan.spring.osgi.dao
Built-By: krel
Tool: Bnd-0.0.255
Bundle-Name: demo-spring-osgi-dao
Created-By: Apache Maven Bundle Plugin
Bundle-Version: 1.0.0.SNAPSHOT
Build-Jdk: 1.6.0_03
Bnd-LastModified: 1211919191482
Bundle-ManifestVersion: 2
Import-Package: net.krecan.spring.osgi
Bundle-SymbolicName: net.krecan.spring-osgi.demo-spring-osgi-dao

It says that I am importing package net.krecan.spring.osgi. That's the package where the interfaces are defined in. And I am exporting this package again, since I am publishing implementation of one of the interfaces. (Well, I am not sure if its true, but it did not work, when this package was not exported.) All other packages are private. It means, that they can not be used be other bundles. Wow, it is something like Java 7 superpackages.

Ok, OSGi is almost configured, the only think we need to do is to define the service. But again, I am to lazy to learn OSGi. What to do? What about Spring?. Spring provides support for OSGi. So I can export whatever Spring bean I want as an OSGi service. The only think I have to do, is to put following XML file into META-INF/spring directory.

<?xml version="1.0" encoding="UTF-8"?>
<beans ...>

	<osgi:service ref="dataLoader"
		interface="net.krecan.spring.osgi.DataLoader" />

	<bean id="dataLoader"
		class="net.krecan.spring.osgi.dao.DefaultDataLoader" />

(Full version can be downloade here)

I am publishing dataLoader bean as an implementation of DataLoader interface. Later on, when some other bundle will look for the service, it will just say, that it wants implementation of this interface and OSGi will find it.
And that's it. I have created my first OSGi bundle. What? You do not believe that it works? Ok, I will test it using Spring OSGi testing support. We will write simple integration test.

package net.krecan.spring.osgi.dao;

import net.krecan.spring.osgi.DataLoader;

import org.osgi.framework.ServiceReference;
import org.springframework.osgi.test.AbstractConfigurableBundleCreatorTests;
import org.springframework.osgi.test.platform.Platforms;

 * Tests the DAO bundle.
 * @author Lukas Krecan
public class DaoOsgiTest extends AbstractConfigurableBundleCreatorTests {

private static final String DEMO_VERSION = "1.0-SNAPSHOT";

	protected String getPlatformName() {
		   return Platforms.FELIX;
	protected String[] getTestBundlesNames() {
		return new String[] {
			"net.krecan.spring-osgi, demo-spring-osgi-dao, "+DEMO_VERSION, 
	 * The superclass provides us access to the root bundle
	 * context via the 'getBundleContext' operation
	public void testOSGiStartedOk() {
	public void testGetDataLoader() throws Exception {
		ServiceReference ref = bundleContext.getServiceReference(DataLoader.class.getName());
        assertNotNull("Service Reference is null", ref);
        try {
        	DataLoader dataLoader = (DataLoader) bundleContext.getService(ref);
            assertNotNull("Cannot find the service", dataLoader);
            assertNotNull("Data are null", dataLoader.loadData());
        } finally {

The test extends AbstractConfigurableBundleCreatorTests which takes care of starting OSGi engine (Apache Felix in this case) and loading all necessary bundles. The only think we have to specify is the name of the bundle under test. (The test loads the bundles from the local Maven repository by default.) We can than test whether the bundle is started and the service is running.

That's all for today, in the next part we will discuss UI bundle and the service bundle. I will be glad for any feedback, so if you will spot any mistake in the text, please let me know. Of course I accept the compliments as well.

Source code is accessible in here.

7 Responses to “Let’s play with OSGi, Spring and Maven, part 1”

  1. Honza Novotný Says:

    You have my copliment 😉 . It's nice short and well understandable article.

    I have been thinking about different thing since last CZJUG - and that is, whether OSGI could help to minimize classloader leak problems in web application. From the speech of Michal Malohlava I assume that it does not.

    OSGi is mostly about dynamic installing and uninstalling bundles - but when the bundle you are uninstalled haven't clear all its references and memory allocated for it could not be GCed, this principle goes in vain. And - leaking memory in web programming is SOOO easy. As I understand OSGi wouldn't help to solve this problem, more than that - by its nature OSGi will create dozens of classloaders, so it is possible much harder to find out what's going in. Finally, when you leak classloaders, you'll run out of PermGenSpace memory and you wouldn't be able to dynamicaly install/uninstall modules at all.

    Am I right or miles out?

  2. Lukáš Křečan Says:

    If you do not know, ask the machine. We can do a small experiment. I will try to write about it in part 3.

  3. Honza Novotný Says:

    Thanks, that would be much interesting.

  4. Getting started with Maven2 « Wordpressblog Says:

    [...] •Nice tutorial for Spring / OSGI and Maven2 •Maven Getting started guided •How can Maven benefit my development process •The pain of switching from Ant to Maven (very good post, funny too read, thoughts of developer migrating I am sure I will suffer the same) •Maven2 Eclipse Plugin •Better builds with Maven (Free E-Book) [...]

  5. Geir Pettersen Says:

    Very nice tutorial. I am however having some problems with building it as some of the tests fails - example (output from maven):

    Tests in error:
    testOSGiStartedOk(net.krecan.spring.osgi.dao.UiOsgiTest): C:\Users\Geir\.m2\repository\org\slf4j\slf4j-api\1.4.3\slf4j-api-1.4.3.jar

    Similar error occurs when i try to run the test from within Eclipse.

    I can't see slf4j-api-1.4.3.jar anywhere in the dependency hierarchy so I added it to the -it project hence it got loaded into my local repository. However, the test then failed on another library:

    Tests in error:
    testOSGiStartedOk(net.krecan.spring.osgi.dao.UiOsgiTest): C:\Users\Geir\.m2\repository\org\springframework\osgi\aopalliance.osgi\1.0-SNAPSHOT\aopalliance.osgi
    -1.0-SNAPSHOT.jar (The system cannot find the path specified)

    I really don't understand why it's complaining about a missing library that is not found in the pom dependency hierarchy - the only logging library I find is log4j, no slf4j...

    I've tried using both Maven 2.2.1 and 3.0.3 as well as cleaning my local m2 repository.

    Any thoughts?

    Thank you!

  6. Geir Pettersen Says:

    I got it working, after adding the following dependencies to the integration test project:





    Was this just left out by accident or is there something else that is wrong when I need to add these dependencies....?


  7. Geir Pettersen Says:

    Trying again, escaping < and > :