Vaadin resources aren't loaded from my OSGI bundle

I have a set of bundles I created with Maven + BND. One of the bundles contains my Vaadin “Application”, the others have some utilities and additional editors.

I can run this app on a Tomat server - everything is OK. Then I tried running in OSGI (Apache Felix). After many solved problems I finally managed to run the OSGI runtime and have all the bundles loaded and activated correctly.
I can even access the 1st page with “localhost:8080/bat”

now the problem is that the app can’t load its Vaadin resources (CSS, maybe widgetset, etc). The start page shows some unformatted text from my app only.
the debug frame says:

Starting Vaadin client side engine. Widgetset: com.vaadin.terminal.gwt.DefaultWidgetSet
Widget set is built on version: 6.6.6
Warning: widgetset version 6.6.6 does not seem to match theme version
Starting application bat-97301
Vaadin application servlet version: 6.6.6
Application version: 0.0.1
inserting load indicator
Making UIDL Request with params: init
Server visit took 9ms

Assuming CSS loading is not complete, postponing render phase. (.v-loading-indicator height == 0)
Assuming CSS loading is not complete, postponing render phase. (.v-loading-indicator height == 0)

CSS files may have not loaded properly.

so, it looks like Vaadin resources can’t be loaded. what’s a proper structure for a Vaadin application packed as an OSGI bundle?
here’s mine (created with Maven + BND) - see the attached screenshot.
11899.png

Hi,

Just a quick note: if you did not already, then have a look at the
Vaadin OSGi add-on
and/or its
source on GitHub
… IIRC it contains functionality for serving static resources.

Best Regards,
Marc

The proper structure is to create a OSGi fragment for the theme and widgetset and attaching this to the org.vaadin bundle. This is actually mandatory, since the OSGi classloading mechanism will deny any attempts of loading your application theme (or anything else) if the call originates outside the application bundle (in this case the caller is the vaadin bundle itself). The only way for the Vaadin bundle to find your files is attaching them to the org.vaadin bundle as a fragment bundle.

There are instructions for this in the mentioned Vaadin-OSGi addon, specifically Vaadin-OSGi-staticres.

Hope this helped, I know how confusing OSGi can be for a beginner :slight_smile:

According to this you cannot have a Fragment attached to multiple hosts which from my understanding means you would have to deploy multiple static resource Bundles for each Vaadin application you wanted to deploy:

http://blog.linkedin.com/2008/07/10/osgi-at-linkedin-integrating-spring-dm-part-2/

Although I understand its not desirable to serve static resources out of the Vaadin OSGi bundle in a production environment it would be nice to have that capability for ease of deployment. I’m sure you could do some clever Apache configuration to make it all work with a single copy.

Thanks Marc and Thomas for the hint!

I’m now using the Vaadin-OSGi-staticres bundle and attached a fragment to “com.vaadin”.

When I add the widgetset folder structure to the fragment and export its packages, the “nocache.js” will be offered to the app on the following path:

localhost:8080/VAADIN/de/testsystem/widgetset/MyWidgetSet/de.testsystem.widgetset.MyWidgetSet.nocache.js

However, the widgetset is searched here:

localhost:8080/VAADIN/de.testsystem.widgetset.MyWidgetSet/de.testsystem.widgetset.MyWidgetSet.nocache.js

The problem here is that one can only export packages from a fragment, and there cannot be one single package with the name “de.testsystem.widgetset.MyWidgetSet” (this would rather be a hierarchy of several packages).

Putting the widgetset in the root folder for creation, such that its complete name would be “MyWidgetSet” instead of “de.testsystem.widgetset.MyWidgetSet” wouldn’t solve the problem, since there is a folder named “MyWidgetSet-deploy”, which wouldn’t be a valid package name either.

Haven’t found a solution yet…

Did anyone else face this problem, too?

A workaround to my problem actually is to rename the widgetset from “de.testsystem.widgetset.MyWidgetSet” to simply “MyWidgetSet” and ignore the “MyWidgetSet-deploy” folder. Then it can be exported as a package in the Fragment. But I guess there are nicer solutions…