Vaadin and OSGi - Problem with /VAADIN/* url

Based on the article Creating a Modular Vaadin Application OSGi by Petter Holmström, I download the source code and adjust the ant script to my settings. I get everything build with ant and deployed to Glassfish V3.1. All OSGi bundles are properly installed and active in Apache Felix.

Instead of the vaadin.jar in the article I use the newest release of vaadin → vaadin.6.6.0.jar.

As I open http://localhost:8080/moduledemo Vaadin complains Failed to load Widgestset …

So I modify the source and add the “/VAADIN/*” to the URL mapping.

        @WebServlet(urlPatterns = {"/*", "/VAADIN/*"})
	public static class Servlet extends AbstractApplicationServlet {

		@Resource(mappedName = "vaadin-moduleService")
		ModuleService moduleService;

		protected Class<? extends Application> getApplicationClass() {
			return ModuleDemoApp.class;

		protected Application getNewApplication(HttpServletRequest request) throws ServletException {
			return new ModuleDemoApp(moduleService);


Still didn’t work. Can somebody give me a hint or advice how to get the example run?


Vaadin 6.6.1 is deployed as an OSGI bundle on Glassfish 3.1 (asadmin deploy --type osgi vaadin-6.6.1.jar)
My webapp is deployed as a hybrid OSGI webapp on Glassfish 3.1 (asadmin deploy myapp.war)

Accessing myapp in firefox gives…
Failed to load the widgetset: /myapp/VAADIN/widgetsets/com.vaadin.terminal.gwt.DefaultWidgetSet/com.vaadin.terminal.gwt.DefaultWidgetSet.nocache.js?1307605103735

Adding vaadin-6.6.1.jar to WEB-INF/lib fixes the issue but that’s just wrong.

I upgrade to Glassfish 3.1.1. Same behavior. I install vaadin-6.6.3.jar as bundle. Install module service and modules via Gogo Remote Shell via telnet. Works.

Glassfish logs

2011-08-08T17:12:05.689+0200   INFO  
Requested resource [VAADIN/widgetsets/com.vaadin.terminal.gwt.DefaultWidgetSet/com.vaadin.terminal.gwt.DefaultWidgetSet.nocache.js]
 not found from filesystem or through class loader. Add widgetset and/or theme JAR to your classpath or add files to WebContent/VAADIN folder.

I read all your articles. AbstractApplicationServlet is subclassed, but doesn’t seem to work.

Unlike Matthew I extract only the widgetsets. There is no error message anymore. Is this the only workaround?

Previously: I Install the Web Application as usual WAR via Glassfish Web Console.

Now: I adjust my pom.xml to create a WAB (Web Application Bundle). Installed as bundle within Apache Felix/Glassfish.

EDIT: There is still a VAADIN url error. Have to add the widgetset and theme to my WAB.

I’m still confused. My understanding of the article is, that it will also works with AbstractApplicationServlet.

You can make a VAADIN dir under your bundle root.
and, in web.xml, add:

Application widgetset
your Widgetset


I am using Vaadin 6.7.3 in Glassfish 3.1.1 and my application is packaged as a WAB. I am getting Failed to load the widgetset: /2/VAADIN/widgetsets/com.vaadin.terminal.gwt.DefaultWidgetSet/com.vaadin.terminal.gwt.DefaultWidgetSet.nocache.js?1327199815227 errors too.

I have tried Neil Bartlett’s
and Christopher Brind’s
but both of them automatically registers a subclass of the AbstractApplicationServlet using the HttpService

At the mean time, I have crudely solved this by subclassing ServletContext’s getResource to get the resource from the vaadin bundle itself (Bundle.getResource)

I’m using Vaadin 6.7.4 with the latest GA Glassfish 3.1.1. I’ve observed that only VAADIN/theme/* are exported and do indeed get served ok. What seems to be missing is the /VAADIN/widgetset/* in the ‘Export-Package’ from MANIFEST.MF:

Export-Package: VAADIN.themes, VAADIN.themes.base, VAADIN.themes.base.
absolutelayout, VAADIN.themes.base.accordion, VAADIN.themes.base.butt

This seems to be an oversight.


http://localhost:8080/HelloWorldOSGi /VAADIN/themes/reindeer/styles.css
http://localhost:8080/HelloWorldOSGi /VAADIN/themes/base/common/img/loading-indicator.gif

404 error:


The HelloWorld OSGi example would work out of the box without needing the Vaadin OSGi add-on if it exported these resource if I understand the issue correctly.

Vaadin OSGi addon is only needed if you need to use Vaadin with HttpService in OSGi (those with context roots prefixed with osgi/). The themes do get loaded because they’re exported and default widgetsets would work if they were exported too but I think they weren’t because it would not work with custom widgetsets.

We’re using this markup in our plugin.xml to solve the problem:

To keep it portable I decided to use OSGi bundle fragments along with Servlet 3.0 feature which loads resources from /META-INF/resources as if it were root. This way I can easily add custom widgets and CSS static resources. It also makes a handy archive that I could unzip in a Apache server if I choose to use a web server in front of app serer.

Here’s my Gradle build script that I used:

apply plugin: 'java'

configurations {

dependencies {
	vaadin 'com.vaadin:vaadin:6.7.5'


jar {

	manifest {
            'Bundle-ManifestVersion': '2',
			'Bundle-SymbolicName': 'textura.web.app1.resources',
			'Bundle-Name': 'Textura Application 1 WAB static resources fragment',
			'Bundle-Vendor': 'Textura',
			'Fragment-Host': 'textura.web.app1'

	from(zipTree(configurations.vaadin.singleFile)) {
		include 'VAADIN/**/*'

For those using the pax-vaadin-service:

Do not use the pax-vaadin-service-bundle hosted at the maven repositories. It may contain an incorrect implementation for registering the /VAADIN resources in it’s bundle activator.

My case: I installed the the pax-vaadin-service-bundle by the means of the karaf-feature-install, where the bundle got resolved somewhere from public maven repositories. After all attemps to start my application were in vain, I took a closer look at the pax-vaadin-service’s bundle activator, et voila, it does something like this

props.put("sling.servlet.paths", "/VAADIN");

which is kinda outdated or does only work in combination with sling, that I do not have here.

The way it should go is, to register the VAADIN resources for the “alias” key

props.put("alias", "/VAADIN");

as it is demonstrated here:

So make sure your pax-vaadin-service-bundle is using this version of the bundle activator.

That’s the way I solved this issue for me.

BE AWARE, that (unfortunately) both implementations are of the same version: 0.1.0.SNAPSHOT

and remember karaf-users, DO NOT DO THIS:
karaf@root> features:install org.ops4j.pax.vaadin.service