Vaadin OSGi

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.

- org.uk.brindy.guessit.jar - an example application (a number guessing game)

All bundles contain source and weigh in at a hefty 36KB! ;-)

What do you think?

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

Cheers,
Chris

Christopher Brind: 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.

- org.uk.brindy.guessit.jar - an example application (a number guessing game)

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 and add-on package spec.

OK, that's published:
http://vaadin.com/directory#addon/109

If you have time to check it, I'd appreciate it. :)

Thanks,
Chris

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)

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 :)

Cheers,
Chris

I wouldn't want people thinking it only works with Felix :)

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! ;-)

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. :)

Cheers,
Chris

Joonas Lehtinen: 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 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.

2) 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.

Thanks,
Sahoo

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:
http://maven.glassfish.org/content/groups/glassfish/org/glassfish/osgi-http/3.1-SNAPSHOT/osgi-http-3.1-SNAPSHOT.jar
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.

Thanks,
Sahoo

Sanjeeb Kumar Sahoo: 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.

2) 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

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)

Sanjeeb Kumar Sahoo: 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.

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

Sanjeeb Kumar Sahoo: 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:
http://maven.glassfish.org/content/groups/glassfish/org/glassfish/osgi-http/3.1-SNAPSHOT/osgi-http-3.1-SNAPSHOT.jar
and copy it to the glassfish/modules/autostart/ directory or glassfish/domain1/autodeploy/bundles/ directory. No, need to restart glassfish.

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.

Thanks,
Chris

Christopher Brind: 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.

Thanks,
Chris

Hi Sahoo,

I now get the following exception:

[#|2010-04-15T11:37:45.305+0100|SEVERE|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=24;_ThreadName=SCR Component Actor;|java.lang.RuntimeException: javax.servlet.ServletException: java.lang.NullPointerException
	at org.vaadin.osgi.VaadinOSGiApplicationManager$1.run(VaadinOSGiApplicationManager.java:126)
	at org.vaadin.osgi.VaadinOSGiApplicationManager.start(VaadinOSGiApplicationManager.java:85)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:213)
	at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:38)
	at org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:542)
	at org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:434)
	at org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:138)
	at org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226)
	at org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:118)
	at org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:991)
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:298)
	at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.doRun(AbstractComponentManager.java:505)
	at org.apache.felix.scr.impl.ComponentActivatorTask.run(ComponentActivatorTask.java:67)
	at org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:96)
	at java.lang.Thread.run(Thread.java:637)
Caused by: javax.servlet.ServletException: java.lang.NullPointerException
	at org.glassfish.osgihttp.GlassFishHttpService.registerServlet(GlassFishHttpService.java:102)
	at org.glassfish.osgihttp.HttpServiceWrapper.registerServlet(HttpServiceWrapper.java:90)
	at org.vaadin.osgi.VaadinOSGiApplicationManager$1.run(VaadinOSGiApplicationManager.java:124)
	... 18 more
Caused by: java.lang.NullPointerException
	at java.util.Hashtable.put(Hashtable.java:394)
	at java.util.Properties.setProperty(Properties.java:143)
	at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.init(AbstractApplicationServlet.java:206)
	at org.glassfish.osgihttp.OSGiServletWrapper.initializeServlet(OSGiServletWrapper.java:81)
	at org.glassfish.osgihttp.GlassFishHttpService.registerServlet(GlassFishHttpService.java:100)
	... 20 more

I'm using the following versions:

- GlassFish v3 (build 74.2)
- glassfish-osgi-http 3.0.1-12 from dev.glassfish.org

Thanks in advance.

Joonas Lehtinen:

Sanjeeb Kumar Sahoo: 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.

2) 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

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)

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 StaticResources.java 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: https://glassfish.dev.java.net/issues/show_bug.cgi?id=11797
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:
felix.fileinstall.dir=/home/ss141213/bugs/vaadin/vaadin-sample/plugins/

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

Thanks,
Sahoo

Christopher Brind: Hi Sahoo,

I now get the following exception:

Caused by: java.lang.NullPointerException
	at java.util.Hashtable.put(Hashtable.java:394)
	at java.util.Properties.setProperty(Properties.java:143)
	at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.init(AbstractApplicationServlet.java:206)
	at org.glassfish.osgihttp.OSGiServletWrapper.initializeServlet(OSGiServletWrapper.java:81)
	at org.glassfish.osgihttp.GlassFishHttpService.registerServlet(GlassFishHttpService.java:100)
	... 20 more

I'm using the following versions:

- GlassFish v3 (build 74.2)
- glassfish-osgi-http 3.0.1-12 from dev.glassfish.org

Thanks in advance.

Christopher,

I think you have encountered https://glassfish.dev.java.net/issues/show_bug.cgi?id=11797. 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.

Sahoo

Christopher Brind:

Sanjeeb Kumar Sahoo: 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.

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).

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.

Christopher Brind:
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.

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

Sahoo

Sanjeeb Kumar Sahoo: 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.

Isn't org.vaadin.osgi.VaadinOSGiApplicationManager.cfg ?

Anyway, this isn't required (shouldn't be) unless you want to make Vaadin run in production mode. Which of course you probably will in a production environment. :)

Sanjeeb Kumar Sahoo: b) There is a bug in Vaadin supplied StaticResources.java 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())) {

Exactly the fix I have made. :)

Christopher Brind:

Sanjeeb Kumar Sahoo: 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.

Isn't org.vaadin.osgi.VaadinOSGiApplicationManager.cfg ?

You are right. It is org.vaadin instead of com.vaadin.

Christopher Brind:

Sanjeeb Kumar Sahoo: b) There is a bug in Vaadin supplied StaticResources.java 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())) {

Exactly the fix I have made. :)

Actually I noticed one more bug in vaadin when I tried to use it in GlassFish. When I initially deployed your vaadin sample, I noticed it didn't get resolved because GlassFish comes with an older version of SCR bundle and vaadin requires newer version. I actually don't know if vaadin really requires newer version or it is not configured correctly. Any way, to get past the problem, I installed a newer the SCR bundle in my glassfish installation. Then I noticed that the servlet registration failed with errors like:
org.osgi.service.http.NamespaceException: alias already registered
Anytime there is more than one SCR bundle, vaadin is trying to register the same alias as many times as there are SCR bundles. SO, I had to make sure that only SCR bundle is available in GlassFish installation. I think vaadin code should be fixed.

BTW, I didn't mention that once the helloworld app is deployed in GlassFish, to access it, one has to access the following URL:
http://localhost:8080/osgi/helloworld
All OSGi servlets are registered under a separate namespace called osgi in GlassFish, because we feel the default doc root is reserved for other use.

Sahoo

Sanjeeb Kumar Sahoo: Actually I noticed one more bug in vaadin when I tried to use it in GlassFish. When I initially deployed your vaadin sample, I noticed it didn't get resolved because GlassFish comes with an older version of SCR bundle and vaadin requires newer version. I actually don't know if vaadin really requires newer version or it is not configured correctly. Any way, to get past the problem, I installed a newer the SCR bundle in my glassfish installation. Then I noticed that the servlet registration failed with errors like:
org.osgi.service.http.NamespaceException: alias already registered
Anytime there is more than one SCR bundle, vaadin is trying to register the same alias as many times as there are SCR bundles. SO, I had to make sure that only SCR bundle is available in GlassFish installation. I think vaadin code should be fixed.

As far as I'm aware the result of running multiple SCRs is unspecified. I don't think it is reasonable for my component to have logic in it to make sure it is only instantiated once, that is why I am using SCR in first place.

And since that particular error occurs it must mean that there is already an active instance of the component (because otherwise the resource would not have been registered with the http service).

The general guideline here is not to run multiple SCRs, one should be enough and a newer one should be backward compatible.

Cheers,
Chris

just started with Vaadin...

Vaadin has great UI Components and I like the way to develop all at server-side,
but only reason that I'm really using Vaadin is because it runs under OSGI ;-)
..was inspired by Kai's blog about Vaadin + OSGI (http://www.toedter.com/blog/?p=412)

Vaadin + OSGI works great (I'm using Equinox)
now I want to use some add-on's

did I understand right:
Add-Ons have to be Fragments of vaadin.com bundle ?

is there a short description / doc how to use add-on's with Vaadin-OSGI ?

thx for tips

ekke

background:
I'm in the process of developing an (Open Source) PushService Server (supporting Push Service SDK's from BlackBerry, Android, iOS, WP7)
complete server is leightweight OSGI (Equinox)
Admin / Management / Monitor - UI will be available for Desktop-RCP (Eclipse Riena), from mobile devices and as Web-Solution using Vaadin-OSGI
will blog about the solution in detail later...

for now I have done this:

tested with a very small add-on: QRCode

started Eclipse based on JavaEE with Vaadin PlugIn
added qrcode.jar
widgetsets wre automatically compiled

switched to another eclipse installation containing Vaadin-OSGI bundles - of course using the same Vaadin com version then the EE-Installation

added a new PlugIn - created from qrcode.jar - exporting the packages and required bundle vaadin com

edited an existing bundle and added the QRCode as component of a view

created also a new fragment of vaadin com as host bundle.
added a src-package 'widgets'
copied from Java EE installation - WebContent: folder VAADIN/widgetsets/*
exported non-java-package VAADIN.widgetsets from Fragment Bundle

started the OSGI application

browser doesn't display the QRCode and reports an error:

Widgetset does not contain implementation for fi.jasoft.qrcode.QRCode.
.... fi.jasoft.qrcode.QRCode(NO CLIENT IMPLEMENTATION FOUND)

did I miss anything ?

found it:

copying widgetsets to and exporting from fragment bundle isn't all that must be done:

you have to add an argument like

-Dorg.vaadin.osgi.widgetset=your_custom_widgetset_from_VAADIN.widgetsets

Hi,

Since now I have played with Vaadin + OSGi tutorial http://vaadin.com/wiki/-/wiki/Main/Creating%20a%20Modular%20Vaadin%20Application%20with%20OSGi and I would like to use UI component addons in my bundle modules. I tried with the Switch addon, made it a bundle with the maven plugin but unfortunately it can not be loaded by the OSGI container because it is missing some *gwt* packages (this way I assumed that also some GWT libraries must be deployed as bundles).
What I want is different addons to be deployed as bundles and be consumed used in different modules of the application.
I also understood that addons must be compiled in the parent WAR and this is kind of coupling the application WAR with the addons used by independent modules.
So my question is, can you please provide a complete step-by-step example of the right way of using addons in an OSGI environment?

Thanks,
Georgian Micsa

Georgian Micsa: Hi,

Since now I have played with Vaadin + OSGi tutorial ...
So my question is, can you please provide a complete step-by-step example of the right way of using addons in an OSGI environment?

Thanks,
Georgian Micsa

Hi,

you're in luck ;-)

I'm just working (together with Florian Pirchner) on a new (Open Source) project redVaadin.org and documented about:

HowTo use Vaadin and OSGI
HowTo use Vaadin Add-ons with OSGI
HowTo push to Clients from OSGI Server using ICEpush

stay tuned.... we'll blog about this new project soon

ekke

Hi, I'm using your addon for a project and ran into difficulties with defining servlet parameters. Where/how should productionMode, widgetset and session-timeout be set?

I'm running on JBoss-osgi that is based on Felix.

is it possible to upload "org.vaadin.osgi.*" bundles to Maven Central?

TIP:
If someone's Vaadin component is not working:
Set Component's "Factory Id" to "vaadin.app".

I can't seem to find this anywhere in the docs - can someone point me to the right location?

Ekkehard

I am stuck exactly as you described, I am deploying my karaf in tomcat. I am deploying portallayout and it does not display it as portallayout, in short, no client resources are being used for the particualr addon.

I wanted to find out the context in which this solution works?

Thanks in advance.
- Ana

Can you please explain what is org.vaadin.osgi? IS this a bundle?
- Anu