In this article Scott Lewis go even further and showcase a Twitter user status service with GWT, OSGi and Amazon Web services:

Using several technologies, I’ve recently created a Twitter user status service…i.e. a web service that retrieves the latest user status for a given user.

Read the complete article here.

Last week the Apache CXF implementation of the OSGi Remote Service specification, CXF-DOSGi version 1.1 was released.The CXF-DOSGi code base has already been supporting the OSGi Remote Service spec (chapter 13 in the OSGi 4.2 Compendium Specification) for some time. Now it’s in a released version as well.

Read the complete article on David Bosschaert’s blog.

The OSGi HTTP Service provides a simple OSGi service to deploy servlets and resources at runtime; in this article I’ll focus on the first part, implementing and deploying a simple Servlet.

First of all, you will need an OSGi HTTP Service implementation. As usual, Apache Felix provides a framework-independent bundle; so, without further ado, you can download it and install it in your OSGi container, or simply type

$ pax-run.sh http://www.osgilook.com/static/samples/osgi-http-service.txt

(By the way: have a look at our OSGi Demos for other easy, pre-cooked, demos)

Let’s now develop a simple Servlet. You don’t need to make it OSGi dependent in any way, so the usual Hello World Servlet would work:

public class DateServlet extends HttpServlet
{
	@Override
	protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException
	{
           resp.getWriter().write("Hi, today is "+ new Date());
	}
}

Easy. Now let’s write the usual deployment descript… no way! We want to deploy it on the fly, and without any boring XML descriptor!
What we need is to get access to the OSGi HttpService, and declare the new servlet. We can do that, as usual, in the bundle activator.

public class Activator implements BundleActivator
{
   public void start(BundleContext context) throws Exception
   {
      ServiceReference sRef = context.getServiceReference(HttpService.class.getName());
      if (sRef != null)
      {
         HttpService service = (HttpService) context.getService(sRef);
         service.registerServlet("/date", new DateServlet(), null, null);
      }
   }

   public void stop(BundleContext context) throws Exception
   {
      ServiceReference sRef = context.getServiceReference(HttpService.class.getName());
      if (sRef != null)
      {
         HttpService service = (HttpService) context.getService(sRef);
         service.unregister("/date");
      }
   }
}

Now package your bundle (don’t forget to specify the Bundle-Activator) and deploy it in the running OSGi container. If everything works fine, you’ll be able to reach your servlet at http://localhost:8080/date.

There are a few things the OSGi HTTP Service can also do, like registering resources. I’ll talk about that in the next blog post.

You can find more details on his “Pax My Framework” blog.

Let’s take it for a test drive.

First of all, to install the Knopflerfish HTTP Console you will need:

• the OSGi Compendium Bundle: http://repository.ops4j.org/maven2/org/osgi/org.osgi.compendium/4.1.0/org.osgi.compendium-4.1.0.jar
• an OSGi HTTP Service Implementation: http://apache.prosite.de/felix/org.apache.felix.http.jetty-1.0.1.jar
• and of course the Knopflerfish HTTP Console jar: http://www.knopflerfish.org/repo/jars/httpconsole/httpconsole-2.0.1.jar

The other important thing you need is to set the org.osgi.service.http.port property value; in fact, by default, the Http Service will try to start at port on port 80, causing an exception of Unix systems.

Feeling lazy (every developer is lazy..)? I’ve prepared a Pax-Runner file for you. Assuming you have Pax Runner installed, just type

$ pax-run.sh http://osgilook.com/static/samples/kf-http-console.txt

and you are ready to rock!

Now opening your browser at http://localhost:8080/servlet/console you have access to the Knopflerfish console in all its glory.

The functionalities offered by this tool are pretty basic. There’s the Bundle View, where you can see its headers and services exposed:

It is possible to select a single service to display all its properties:

And it’s of course possible to install a bundle directly from the web interface:

In summary, the functionalities offered are just basic compared to the Apache Felix Web Console; however, being the user interface so simple (and usable also with small screens), it’s quite ideal if you want to check the status of your OSGi framework deployed on a mobile device.
Want to know more?

$ pax-run.sh http://osgilook.com/static/samples/kf-http-console.txt

Cannot be simpler than that!

Since I use it when I’m writing articles for the OSGi Look, I decided to publish the provisioning files I write in the new OSGi Demos section. That will give you the opportunity to try bundles and OSGi applications in less than 2 minutes, just running a one-line command.
Give it a try!

Finally, if you know any interesting (and open source) OSGi application/demo that you can run with a Pax-Runner file, just send it to me and I’ll publish it.

OSGi of course is not immune to that problem; an OSGi bundle may run in any device supporting a R4 OSGi container, and therefore needs a well defined and portable mechanism to store application and user settings. That’s the business of the OSGi Preferences Service.

In this article I’m going to show how you can use the Preferences Service in your OSGi applications.

First of all, you need an implementation of the OSGi Preferences Service. Apache Felix provides, as usual, a portable implementation that you can download and use in any R4 container: you can download the jar here and check the documentation here.

After you have downloaded and installed the bundle in your OSGi container, accessing to the Preferences Service is as simple as using any other service in OSGi:

ServiceReference serviceref = context.getServiceReference(PreferencesService.class.getName());
if (serviceref != null)
{
   PreferencesService preferences = (PreferencesService) context.getService(serviceref);
   //store and retrieve your preferences here
}

Preferences are organized in a tree structure, so you can define quite complex preference models; the only limitation is give by the fact that you can store on “simple” values (boolan, double, float, int, long and strings) and not any type of Java object.

As mentioned before, the Preferences Service can be used to store application and user settings. To store application settings, you will place your settings under the system root.
Let’s see in the following example how an application can store the information gathered during the installation:

ServiceReference serviceref = context.getServiceReference(PreferencesService.class.getName());
if (serviceref != null)
{
   PreferencesService preferences = (PreferencesService) context.getService(serviceref);	

   //create a node 'installation' under the system root
   Preferences installationPreferences = preferences.getSystemPreferences().node("installation");
   installationPreferences.put("path", "/opt/myapp");   //path chosen by the user
   installationPreferences.put("license-key", "687-6GH-9JU-35H");   //license key
   installationPreferences.put("license-email", "hacker@hackerz.com");   //license owner...
}

Reading these settings is equally simple (note that every getter method has a second argument that specifies a default property value if the one required is not found):

ServiceReference serviceref = context.getServiceReference(PreferencesService.class.getName());
if (serviceref != null)
{
   PreferencesService preferences = (PreferencesService) context.getService(serviceref);	

   //retrieve the  'installation' node under the system root
   Preferences installationPreferences = preferences.getSystemPreferences().node("installation");
   String key = installationPreferences.get("license-key", null);   //get the license key
   String ownder = installationPreferences.get("license-email", null);   //get the license owner
}

Using the same API you can store and read user settings. Instead of accessing the System Root just access the User Root writing:

ServiceReference serviceref = context.getServiceReference(PreferencesService.class.getName());
if (serviceref != null)
{
   PreferencesService preferences = (PreferencesService) context.getService(serviceref);	

   //retrieve the  'installation' node under the system root
   Preferences installationPreferences = preferences.getUserPreferences("John");
}

Need more OSGi articles and tutorial? Check the OSGi Recipes section

In the previous article this week I described a simple project structure using the Apache Felix File Install bundle to allow hot deployment of new bundles.
Another interesting feature of the File Install bundle is its ability to load property files and send them to the OSGi ConfigurationAdmin service; that’s very useful if you want to be able to configure your applications just creating/deleting and updating properties file at runtime. In this post I’ll enhance the project presented in the previous article to include this new functionality.

The new project structure we want to build is represented in the picture.

The difference here is the additional config/application folder, that will be monitored by another instance of File Install; we will be able to create there new property files whose contents will be passed to the OSGi Configuration Admin Service.

First of all, we need an implementation of the OSGi Configuration admin service. We could download and store it in the bundle folder, and than add its path in the felix.auto.start property in the config.properties like we did in the previous article; but it much easier just to download it in the dropins folder… that’s why we created it!

$ cd dropins
$ wget http://apache.mirroring.de/felix/org.apache.felix.configadmin-1.0.10.jar

Now that the Configuration Admin bundle is in the dropins folder, we know that it will be automatically installed when we start up Felix.

To create another instance of File Install we will use… File Install. Just create a file called org.apache.felix.fileinstall-config.cfg in the dropins folder containing a single property:

felix.fileinstall.dir=config/application

Now start Felix

Welcome to Felix.
=================

DEBUG: WIRE: 1.0 -> org.osgi.service.startlevel -> 0
DEBUG: WIRE: 1.0 -> org.osgi.framework -> 0
DEBUG: WIRE: 1.0 -> org.osgi.service.packageadmin -> 0
DEBUG: WIRE: 2.0 -> org.apache.felix.shell -> 1.0
DEBUG: WIRE: 2.0 -> org.osgi.framework -> 0
-> DEBUG: WIRE: 3.0 -> org.osgi.util.tracker -> 0
DEBUG: WIRE: 3.0 -> org.osgi.framework -> 0
DEBUG: WIRE: 3.0 -> org.osgi.service.packageadmin -> 0
felix.fileinstall.poll  (ms)   2000
felix.fileinstall.dir            /opt/myprojects/felix-1.8.0/dropins
felix.fileinstall.debug          -1
felix.fileinstall.bundles.new.start          true
Installed /opt/myprojects/felix-1.8.0/dropins/org.apache.felix.configadmin-1.0.10.jar
DEBUG: WIRE: 4.0 -> org.osgi.framework -> 0
DEBUG: WIRE: 4.0 -> org.osgi.service.cm -> 3.0
Started bundle: /opt/myprojects/felix-1.8.0/dropins/org.apache.felix.configadmin-1.0.10.jar
felix.fileinstall.poll  (ms)   2000
felix.fileinstall.dir            /opt/myprojects/felix-1.8.0/config/application
felix.fileinstall.debug          -1
felix.fileinstall.bundles.new.start          true

and we’re done! The log
felix.fileinstall.dir /opt/myprojects/felix-1.8.0/config/application
confirms that another instance of File Install is watching config/application

All happened too fast? Let’s summarize.

File Install looks for two types of files: .jar and .cfg. When it finds a jar file, tries to install it as a bundle in the OSGi container; when it finds a cfg files, it reads its content, and

• if the file name is something like [service-name]-[service-pid].cfg, it uses the ConfiguratioAdmin service to send the configuration to the ManagedServiceFactory whose service.pid is [service-name]
• if the file name does not contain a – (dash), it sends the configuration to the ManagedService whose service.pid is equal to the file name (without the .cfg extension)

So the trick here is that File Install is started by a ManagedServiceFactory with service.pid equal to org.apache.felix.fileinstall. So when File Install finds the file org.apache.felix.fileinstall-config.cfg in the dropins folder, it reads the contents and send it to its own ManagedServiceFactory that creates another instance of File Install watching the config/applications folder.

Now you are ready to experiment with this new project structure. I’ll leave you with some ideas to try out:

* Read this article explaining how to configure the Apache Felix HTTP service with the Configuration Admin Service; after that, download Felix HTTP servlet in the dropins folder and configure the HTTP port creating a file named org.apache.felix.http containing the property org.osgi.service.http.port

* Also the Felix Web Console exposes a ManagedService under the service.pid org.apache.felix.webconsole.internal.servlet.OsgiManager. Look in the Web Console documentation to find out the properties to change username and password, and create a configuration file in config/application to change the default hacker-friendly admin/admin credentials!