Vaadin and OSGi - Problem with /VAADIN/* url

General
1

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;

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

		@Override
		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?

2

Confirmed.

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.

3

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  
com.vaadin.terminal.gwt.server.AbstractApplicationServlet        
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?

4

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.

5

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


Application widgetset
widgetset
your Widgetset

6

Confirmed.

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
vaadinbridge
 and Christopher Brind’s
vaadin-osgi
 but both of them automatically registers a subclass of the AbstractApplicationServlet using the HttpService

7

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)

8

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.

Works:

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

404 error:

http://localhost:8080/HelloWorldOSGi/VAADIN/widgetsets/com.vaadin.terminal.gwt.DefaultWidgetSet/com.vaadin.terminal.gwt.DefaultWidgetSet.nocache.js?1327704073413

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.

9

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.

10

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

11

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 {
	vaadin
}

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

}

jar {

	manifest {
		attributes(
            '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)) {
		into('/META-INF/resources')
		include 'VAADIN/**/*'
	}
}
12

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:

https://github.com/ops4j/org.ops4j.pax.vaadin/blob/master/pax-vaadin-service/src/main/java/org/ops4j/pax/vaadin/internal/Activator.java

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