Web Applications with OSGi – Static Files


I currently work on migrating an existing web application to OSGi (*).
The current solution relies on Jersey to expose REST services. It also exposes static resources for the web. And what I need to do is to drop Tomcat and deploy it inside an OSGi container. This is the last step to perform to complete our OSGi migration.

(*) Our motivation to use OSGi is classloaders isolation.

Beyond deploying a web application and Jersey services, we also have to plug it with iPojo. iPojo is the framework we chose to define components and services in our application. And to be complete in our description, we will deploy it on Apache Karaf 3.0.x, with Felix as the default container.

Before breaking my application, and given all the things that are involved, I wanted to create a short sample to make sure verything works together. Most of all, and because I did not find a ready-to-use solution on the web, I wanted to determine HOW everything could work together. To be honest, I did not succeeed on the first time. In fact, I have been forced to proceed step by step.

So, this post is the first of a series about web applications in OSGi. And it will start with very simple cases.

Serving Static Files in OSGi

I am NOT going to tell you to write a bundle activator and register a servlet with the HTTP service. Now, OSGi containers support the deployment of web bundles (WAB). This is a ZIP archive that contain both web resources (like in a WAR) and an OSGi bundle. Said differently, it is a WAR file with OSGi metadata in a MANIFEST. And it does not have to use a specific file extension. So, it could also be a JAR file with the structure of a WAR. Using one extension or another depends on your context.

So, here is an example of a WAB that will server static resources. No servlet, no JSP… Since it is very simple, and not dependent on OSGi, I will create a WAR file and add OSGi metadata. This way, I will be able to deploy it in an OSGi container with web support, or in any application server such as Tomcat.

Let’s start with the POM.

<?xml version="1.0" encoding="UTF-8"?>
		xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

	<name>OSGi Sample :: Web App :: Static Files</name>


The project structure must be…

* Your static resources (HTML, CSS, JPG…)
* WEB-INF/web.xml

And here is the content of the web.xml file.

<?xml version="1.0" encoding="UTF-8"?>
		xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" 
		id="WebApp_ID" version="3.0">

	<display-name>Welcome Page</display-name>

The sources are available on GitHub.

Run mvn clean install.
Pick up the WAR file under the target directory and you can directly deploy it in a Tomcat server, or in an OSGi container with web support. How to enable web support in an OSGi container? Well, you can rely on Pax Web. Pax Web is a project that embeds application servers such as Jetty and Tomcat in bundles. Since I deploy on Apache Karaf, I used the WAR feature, which relies on Pax Web.

So, if you are using Apache Karaf, start it and type in feature:install war (or if you are using Karaf 2.x, features:install war). This will enable web support in your installation. And to deploy your web bundle in Karaf, just drop it in Karaf’s deploy directory.

If you want to make sure it is correctly deployed, you can first check in your browser that your resources are displayed at http://localhost:8181/static-files (assuming you kept the default settings for Jetty). And you can also install Karaf’s web console (feature:install web-console) and go to http://localhost:8181/system/console/http (default credentials: karaf / karaf). You will see the HTTP and web contexts there.

Serving a JSP in OSGi

Now, let’s assume you want to use JSP files and have a custom servlet in your web application. What was defined before is still valid. The only modification to bring is in the POM file.

Simply add the following dependency.


Make sure the scope is provided.
The Maven-bundle-plugin will automatically add the package imports in the MANIFEST. And these imports will be provided at runtime by other bundles.

This post is quite detailed.
But I found a lof of information on this blog entry. You may be interested by its reading.

About this entry