Logging with OSGi and knopflerfish

In the previous post Getting started We had prepared our Target platform to run on Equinox and tested it, also we noticed that the logging is not working so today we will configure it on both Equinox and Knopflerfish which is my favourite as it has a very easy to use GUI, which enables developers to easily work with it :)

Now is a resources file like any other resources, the thing is in an OSGi environment you can not inject resources unless you used a fragment to do so. a Fragment is an empty project that has it is own META-INF directory that contains a MANIFEST.MF file to configure the fragment. now we have two options to make a fragment either we do it without a src folder just resources directly or we do make an src folder and put resources in it, now some would say that we don’t need the src folder as we are not going to write any code in the fragment, while this is true you need to know the fact that adding a fragment without src folder will work as expected on Equinox but it wont on knopflerfish, on the other hand making the fragment with src folder that contains the resources will be picked in the expected way by both Equinox and knopflerfish(please note that am not working on felix not yet, but I’ll update this info when I test it).

to sum it up we are going to make a fragment that will deliver resources data for a bundle(in our case it is a to org.apache.log4j),  and we are going to make sure that this bundle will be working correctly on both Equinox and Knopflerfish. So lets get started!

  • We will make a Fragment project, go to:

File –> New –> Other –> Plug-in Development –> Fragment Project


I will call it Log4jConfig , keep the create a java project checked as deiscussed erlier and change the Target Platform to an OSGi framework and choose Equinox!


now we will configure our fragment as shown in the following pic! and note that we can only add one host for each fragment, I have chosen “org.springframework.osgi.log4j.osgi” now click finish.


Now in the src folder make a new file and call it, I have configured one log4j. your workspace should looks like this:


If you take a look at our target folder you will see that we have two bundles provides log4j “org.springframework.osgi.log4j.osgi” and “” and both of them exports the “org.apache.log4j” which will make a conflict when trying to run the project! to solve this we need to deactivate the second one as our fragment is already hosted by “org.springframework.osgi.log4j.osgi”, to do that go to run configurations and un select the the “” from the target platform.


click run and you should see logging on your console!


now we need to test on knopflerfish:

  • To deploy the log4jConfig fragment right click on it and click Export:

plug-in Development –> Deployable plug-ins and fragments

and click next and in the directory choose the OSGi-Target project root. and click finish.


Refresh you OSGi-Target and you will find a new folder called plugins containing a JAR file called log4jConfig_1.0.0.jar


now open Knopflerfish and follow the instructions:

  • add the log4jConfig_1.0.0.jar to it by

File –> Open bundle from file

  • make sure that it is status is installed not resolved. (if it is resolved click on the refresh button).
  • as in first step add the following bundles from our target folder:
  1. aopalliance-1.0.jar
  4. commons-logging-1.1.1.jar
  5. log4j.osgi-1.2.15-SNAPSHOT.jar
  6. spring-aop-2.5.5.jar
  7. spring-beans-2.5.5.jar
  8. spring-context-2.5.5.jar
  9. spring-context-support-2.5.5.jar
  10. spring-core-2.5.5.jar
  11. spring-osgi-annotation-1.1.0.jar
  12. spring-osgi-core-1.1.0.jar
  13. spring-osgi-extender-1.1.0.jar
  14. spring-osgi-io-1.1.0.jar
  15. spring-osgi-mock-1.1.0.jar
  • start them all and make sure to leave the “spring-osgi-extender-1.1.0.jar” to the end (last one to start). you should see the logging on the Knopflerfish console:
  • If you want to turn off Knopflerfish make sure to stop “spring-osgi-extender-1.1.0.jar” as if you don’t when you start Knopflerfish next time logging wont work! because the status of the log4jConfig_1.0.0.jar will be resolved and not installed.


Posted in JAVA


Spring DM-OSGi Getting started

Am using STS as an IDE which is basically eclipse but preloaded with plugins to fit this kinda job! So I’ll be talking about it (every thing should work just fine on any other eclipse). To day I’ll talk on how to prepare the environment to start an Spring DM-OSGi project. we will start with creating a target-platform for the project, which means the set of jars that will be the backbone to run my project.

  • Open your IDE and make a new project by going to

File –> New –> Project…


we will use a plain project for the target-platform name it OSGi-Target and click finish.


  • Now we will extract the OSGi-Target JARs using Maven (a quick maven tutorial can be found here) I have prepared my pom file and you have to make sure to change the following tag with your own value:


create a new folder on the project and call it target


Am using m2eclipse plugin for maven integration. to run the file Right click on the file:

Run as –> maven build…

in the goals field make sure to right package


Click run and maven will download and prepare your target folder you should see something like the following if every thing goes fine!


Now refresh your target folder and you should see the newly installed JARs!

Now we need to make sure that STS/eclipse will run this platform when we make our first bundle!

  • Go to :

Window –> Preferences –> Plug-in Development –> Target Platform

change the location to match your target folder that you made earlier…


click reload and you will see the 22 JARs in your target folder being displayed.

  • We can test our platform now by going to Run-configuration and creating new OSGi Framework, lets call it Target!


click run and you will see that you have a warning on the console says that you don’t have a logging appenders declared(this is what we are going to fix in the next post), we can check our work by typing on the console “ss” which will give us the status of our Target:


That’s it for now and next post we will configure log4j using a fragment.

This is an on going Series and I hope to find some interested people who can help me in it :)

Posted in JAVA


Real Media Converter joins the ArchLinux repository

I have received a mail from a launchpad user that informs me about adding rmconverter to the Arch linux repository…

You can find the package here, also it worth mentioning that it was accepted in the medibuntu repositories and the package can be found here.

Real media converter is meeting a very good success it has been released on 1/1/09 and has a total downloads of 1741 :) more about real media converter can be found here also it can be downloaded from here.

Posted in JAVA


Creating first service

In the previous post we saw how to inject resources to bundles, and today we will make our first service it is going to be a Date formatting service.

you can download the source for this service from dateformattertar and now we will start creating our service…

go to in the same workspace we started before to get advantage of the target platform and the log4j configuration

File –> New –> Other…

And select to create Plug-in project


Click next and name the project DateFormatter and don’t forget to change the target platform to “an OSGi Target”


Click Next and Finish.

In thee newly created project Open the MAINFEST.MF file in the META-INF folder and add the “org.apache.log4j” to the imported packages as we are going to use it.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: DateFormatter Plug-in
Bundle-SymbolicName: DateFormatter
Bundle-Version: 1.0.0
Bundle-Activator: dateformatter.Activator
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Import-Package: org.osgi.framework;version=”1.3.0?,

Now create a sub-package “” And create a new Interface in it with the name DateFormatter


import java.util.Date;

public interface DateFormatter {

String formatDate(Date date);


Now create a sub-package “” And create a new Interface in it with the name DateFormatterImpl


import java.text.SimpleDateFormat;
import java.util.Date;

import org.apache.log4j.Logger;


public class DateFormatterImpl implements DateFormatter {

private String format;

private Logger logger = Logger.getLogger(DateFormatterImpl.class);

public String getFormat() {
return format;

public void setFormat(String format) {
this.format = format;

public String formatDate(Date date) {“formatting a new date”);
SimpleDateFormat formatter = new SimpleDateFormat(format);
return formatter.format(date);


Now all we need to do is to add a spring definition for our classes, spring looks for application context in the META-INF/spring/ so create your application context file there…

<?xml version=”1.0? encoding=”UTF-8??>
<beans xmlns=””
xmlns:xsi=”” xmlns:context=””

<bean id=”formatterImpl” class=””>
<property name=”format” value=”dd-MM-yyyy”></property>

Creating a Registration listener and Importing the service

Now it is very useful to use a registration listener for keeping track of your bundle, Spring DM offers a very good way for doing this, it is by making a new class containing at least two methods which there names are irrelevant -as the class name- but the only constraint is to make the arguments in the both methods take the first argument as reference to the service INTERFACE and the other as a Map to hold the service properties…

package dateformatter.listener;

import java.util.Map;


public class RegListener {

public void reg(DateFormatter formatter, Map map) {
System.out.println(“am here”);

public void unReg(DateFormatter formatter, Map map) {
System.out.println(“am going away”);

Now a wrote another spring context file and put it in the spring folder too, this one to hold the OSGi beans:

<?xml version=”1.0? encoding=”UTF-8??>
<beans xmlns=””

<osgi:service id=”formatter” interface=”” ref=”formatterImpl”>
<osgi:registration-listener  registration-method=”reg” unregistration-method=”unReg”>
<bean class=”dateformatter.listener.RegListener”>

this way I publish a service with a registration listener, to run it you need to run the target platform.

if every thing goes will you will see something like the following:


you can test the registration listener by stopping and running the service.

Next post we will write a client that uses this service…

Posted in JAVA


OSGi and Spring DM Series

Soon I’ll be starting a series of posts about OSGi and Spring DM, this is from my experience about it (which is some kind new), And I will try to shed the light on the problems I faced but did not found enough resources about so I had to figure it out by trail and error! I hope it will be useful and I don’t think t is going to be on a regular bases!

shI will start with the basic definition from the wikipedia:

The OSGi Alliance (formerly known as the Open Services Gateway initiative, now an obsolete name) is an open standards organization founded in March 1999. The Alliance and its members have specified a Java-based service platform that can be remotely managed. The core part of the specifications is a framework that defines an application life cycle management model, a service registry, an Execution environment and Modules. Based on this framework, a large number of OSGi Layers, APIs, and Services have been defined.

Posted in JAVA