Vaadin OSGi


I posted this earlier today and would appreciate any comments.

If you wish to take the OSGi bundle/source I’ve created and make it part of Vaadin, please feel free, though I recommend keeping it separate to the main Vaadin in case people don’t want that functionality.

Let me know what you think.


A really well written article. Recommended reading to anyone interested in using OSGi and Vaadin together.

Hi Joonas,

I was planning to put this OSGi work in to the directory but do you think it is appropriate as it is not an add-on, but another way of running/using Vaadin.

I have renamed the namespace of my bundles to org.vaadin.osgi and now have three bundles:

  • org.vaadin.osgi.jar - the main bundle which allows applications to be dynamically registered with the container

  • org.vaadin.osgi.staticres.jar - a bundle which proxies the static resources in the main Vaadin bundle. Deployment of static resources to a web-server is recommend, so this is provided for development / convenience only.

  • - an example application (a number guessing game)

All bundles contain source and weigh in at a hefty 36KB! :wink:

What do you think?

If you think I should put them in the directory, what is the best way to package them?


IMO they definitely should be put into directory to make it easy for everyone to find them. Miscellaneous category would probably be the best one.

I would package all the three files in a zip - you can use other zip-files like xmlui and jpacontainer as reference. You can find more info on
add-on creation help
add-on package spec

OK, that’s published:

If you have time to check it, I’d appreciate it. :slight_smile:


Tried to deploy this to glassfish 3.0.1. When starting the module, I get There is no installed container capable of handling this application com.sun.enterprise.deploy.shared.FileArchive@3042a8be. Am i missing something really basic? (have not experimented with OSGi before)


I’ve never tried Glassfish to be honest so this message could be any number of things - possibly related to missing dependencies. I’ll give it a try later.

In the mean time, you could try Felix:

Or Equinox (the OSGi container that underpins Eclipse):

I favour Felix right now, but for no particular reason - in theory, either should work.

The procedure with Felix would be to download the following from :

  • Felix Framework Distribution
  • Config Admin
  • SCR (Declarative Services)
  • HTTP Service (API)
  • HTTP Service (Jetty)

Unzip the distribution and copy the bundles (jar files) in to the “bundle” folder.

Also copy all the bundles from my Vaadin-OSGi package and the Vaadin core jar in to the bundle folder.

Then execute the following from the root of the distribution folder:

java -jar bin/felix.jar

Then access http://localhost:8080/guessit

Like I said, I’ll take a look at Glassfish later. :slight_smile:

Works like charm. You might want to add the above instructions to the readme.txt.

I’ve put a link to this thread and will update the description to say look here for instructions for use with Felix.

I wouldn’t want people thinking it only works with Felix :slight_smile:


Good point. You could even list “tested with” or " Also to be noted that most probably this works just fine with glassfish - I was in a hurry and did not look too carefully on the deployment problem (and have no prior first hand experience myself with OSGi+Glassfish combo).

I’ve had a look at running this with Glassfish. I remember why I hate application servers now. Bloated and slow - it’s no wonder you have to cluster them to get performance! :wink:

Your comment about Felix being really lightweight is spot on - we’re running a couple of mid-large scale single VM server applications using Felix. Because it’s so lean all the memory requirements are rock bottom to start with, so scaling up is just a matter of adding more memory to the VM, which we haven’t had to do yet for either of the apps, they are running on default VM settings with between 100 and 1000 users. However, I should point out though that the front end is a Flash client built with Flex and all the server does is handle a small amount of business logic and persistence. I suspect Vaadin would be a little heaver on the memory usage because it will be doing more in the Java space compared to pure client side apps.

Anyway, with regards to Glassfish the main problem is that my vaadin-osgi bundles require the HttpService, which is an interface from the OSGi compendium that allows bundles to register resources that are accessible via a URL. Usually when embedding OSGi in a web application (WAR) you have a ‘bridge’ bundle that provides the HttpService interface, but just delegates to the application server. Neither the HttpService or bridge appear to be available.

It may be that they deliberate designed Glassfish so that HTTP resources have to be registered via a WAR for management purposes or something, but there may well be a way to do this, so I will continue to investigate. Now that app-servers are adopting OSGi more widely I think this is a useful activity. :slight_smile:


I don’t know how you are trying to deploy these bundles to GlassFish to be able to tell what’s exactly causing this exception. The two correct way to deploy OSGi bundles are:

a) You can copy the OSGi bundles to a directory called $glassfish.home/domain1/autodeploy/bundles/. This directory is watched by GlassFish and it installs/updates/uninstalls as and when bundle jars are added/updated/removed.

  1. You can use asadmin cli to dpeloy, but you need to pass in --type=osgi as an option. So, your command would look something like this:
    asadmin deploy --type=osgi /tmp/mybundle.jar

Give any of these a try and let us know. If you find issues while using GlassFish, feel free to as questions in our forum or mailing list.


I don’t agree with the above comments about appservers being bloated and slow. GlassFish starts in seconds and you can customize the stack as per your need. More over, we are also improving this aspect regularly. I won’t go into the details here.

Secondly, if vaadin bundles depend on osgi/http service, GlassFish has one such implementation. It is not distributed as part of our default distribution, but it is available in our package repository (we call it update centre). If you are using v3 final release, then using the admin console (typically accessed via http://localhost:4848), you can browse the update centre and you will find a package called osgi-http. Select it and install.

If you are using 3.1-SNAPSHOTs, then you can download it from:
and copy it to the glassfish/modules/autostart/ directory or glassfish/domain1/autodeploy/bundles/ directory. No, need to restart glassfish.

Having said that, I don’t think the original deployment exception are related to absence of http service. Yes, one would eventually face a problem if the http service is not available.


Hi Sahoo - I tried both the above methods and they failed. Could this problem be related to the Glassfish version? (tried in “unofficial” 3.0.1)

Well, that’s just my opinion, but it is based on the fact that these bundles (and other applications I have been involved with) run fine in a container that has a footprint of about 12mb unpacked. Glassfish is 209mb unpacked, which means that approx 95% of Glassfish is unnecessary (for this activity anyway).

App server downloads seem to contain a lot of “stuff” and it appears that most of it is “just in case”. On a green field project I doubt I’ll ever use an app server again. It feel it’s much better to pull together the bundles as I need them. There are also tools that can help do this, for instance, Paramus Nimble which helps you quickly pull together applications from remote repositories. In fact, Nimble even supports WAR deployment by pulling down just enough to get it going. You can read more here:

Paremus Nimble

I installed it from the update site and it told me I had to restart Glassfish, but I could see from the console that it had been installed.

I redeployed the bundles and get a NPE in my code (even after a restart) but that’s caused by either:

  • at least one null entry in the array returned from bundleContext.getBundles()
  • bundle.getSymbolicName returning null (which I thought wasn’t possible)

I need to check what the spec says about this, but I will harden my code against it anyway.


I checked with my friend and mentor, Neil Bartlett, and it seems the R3 bundles do not have to have a symbolic name. Jar files with no OSGi headers are considered R3 bundles, so if there are JAR files or R3 bundles deployed to the container that could be the source of the NPE.

So I will definitely harden my code against that and release a new version promptly.


Hi Sahoo,

I now get the following exception:

[#|2010-04-15T11:37:45.305+0100|SEVERE|glassfishv3.0||_ThreadID=24;_ThreadName=SCR Component Actor;|java.lang.RuntimeException: javax.servlet.ServletException: java.lang.NullPointerException
	at org.vaadin.osgi.VaadinOSGiApplicationManager$
	at org.vaadin.osgi.VaadinOSGiApplicationManager.start(
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(
	at org.apache.felix.scr.impl.helper.BaseMethod.access$500(
	at org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(
	at org.apache.felix.scr.impl.helper.BaseMethod.invoke(
	at org.apache.felix.scr.impl.helper.ActivateMethod.invoke(
	at org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(
	at org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(
	at org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(
	at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.doRun(
Caused by: javax.servlet.ServletException: java.lang.NullPointerException
	at org.glassfish.osgihttp.GlassFishHttpService.registerServlet(
	at org.glassfish.osgihttp.HttpServiceWrapper.registerServlet(
	at org.vaadin.osgi.VaadinOSGiApplicationManager$
	... 18 more
Caused by: java.lang.NullPointerException
	at java.util.Hashtable.put(
	at java.util.Properties.setProperty(
	at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.init(
	at org.glassfish.osgihttp.OSGiServletWrapper.initializeServlet(
	at org.glassfish.osgihttp.GlassFishHttpService.registerServlet(
	... 20 more

I’m using the following versions:

Thanks in advance.

I just tried helloworld OSGi/Vaadin sample and here are my observations:

a) The sample requires a configuration to be applied. So, one has to copy com.vaadin.osgi.VaadinOSGiApplicationManager.cfg file to autodeploy/bundles/ as well.

b) There is a bug in Vaadin supplied file which can cause a NPE if R3 bundles are encountered. Looking at the comments, I understand that author is already aware of this and has fixed it. I locally fixed the bug in my environment by flipping the equals test like this:
if (“com.vaadin”.equals(bundle.getSymbolicName())) {

c) Once I have gone past the above two steps, I actually discovered a GlassFish bug that was causing NPE in servlet.init() method as the initParams were not correctly populated. I have reported it and also fixed in 3.1 workspace. I am waiting for approval before commiting to 3.0.1 workspace. The bug is filed here:
I am hopeful that in a couple of days, I can fix it in 3.0.1 workspace and then you can pick up a build use it.
In the meanwhile, I am able to deploy and run helloworld sample using my local 3.1 workspace.

Actually, I found a much easier way of deploying vaadin sample in GlassFish. When I downloaded the sample, I found all the necessary bundles and cfg files are located in plugins directory. So, all I had to do was to ask GlassFish to pickup stuff from there. To do so, I created the following file:
domain1/autodeploy/bundles/org.apache.felix.fileinstall-vaadin.cfg. It contains:

Please try to use our forum to ask GlassFish specific questions.



I think you have encountered I discovered this when I tried to use your helloworld sample in GlassFish. As you can see from my comments in the bug, I have already checked in a fix in trunk (i.e. 3.1 workspace) and plan to check in a fix in 3.0.1 workspace upon getting the approval. If you switched to using 3.1-SNAPSHOT builds of GlassFish, then you will find the bug fix.


You don’t need full profile of GlassFish for this experiment, so you could download only web profile. Then again you can remove some stuff web profile and reduce it further. I suggest you lunch admin console, go to update centre tab and remove all those modules that you don’t need.

With GlassFish, this is also possible - we have just not done it yet. It’s coming soon.