Posts Tagged ‘OSGi’

Using the Vaadin (GWT) SuperDevMode in OSGi Environments

July 7, 2015

GWT and Vaadin come with a great feature to debug the client-side widget code in the Chrome browser. Using GWT’s code server, the Java code will be displayed in the Chrome browser, and you can set your breakpoints and do debugging stuff directly in Chrome.

To run the superDevMode some preparations are required:

  1. Enable SuperDevMode in widgetset
  2. Compile your widgetset by a Maven build
  3. Download all dependencies required to run the codeserver (another Maven build)
  4. Create a launch config to run the code server
  5. Enhance the classpath of the code server launch config
    1. Add all downloaded dependencies to the classpath of the code server launch config
    2. Add local client-side code bundles and their source folders to the classpath
    3. Add the widgetset bundle to the classpath
    4. Ensure that 5.2 and 5.3 are at the beginning of the classpath
  6. Start the code server
  7. Start your OSGi Vaadin Application
  8. Open http://localhost:9876/
    1. Bookmark “Dev Mode on” and “Dev Mode off” in the browser
  9. Open your application in Chrome {URL}/?superdevmode
  10. To reload widgetset in 8) click the “Dev Mode on” bookmark
  11. Ensure that Chrome -> Developer tools -> Properties -> Sources -> xyz Sourcemaps are checked
  12. Open the source tab in Chrome and find your java sources there

1 Enable SuperDevMode

To enable the super dev mode, add the following lines to your widgetset.gwt.xml

<set-configuration-property name="devModeRedirectEnabled"
		value="true" />;

<add-linker name="xsiframe" />

2 Compile widgetset

To compile the widgetset properly, we are using a Maven build.

Create a file called pom-compileWidgetset.xml in your widgetset bundle and configure the pom. Therefore just follow Vaaclipse widgetset as a sample.

Following entries in the pom are mandatory:

  1. Add all your maven dependencies required to compile the widgetset
  2. Configure the vaadin-maven-plugin to compile the widgetset. The compiled widgetset will be copied to ${basedir}/resources.

Run the build with “mvn clean verify -f pom-compileWidgetset.xml”

3 Download all dependencies for the CodeServer

To run the code server properly, a lot of jar files are required. The simplest method to collect all dependencies and their transitive dependencies is to use another Maven build.

Create a file called pom-superdev.xml in your widgetset bundle and configure the pom. For this pom, just follow Vaaclipse widgetset as a sample.

The pom contains all required dependencies and a configuration for the maven-dependency-plugin which copies all jar files to a folder under “${}/superDev-lib”. Attention: The superDev-lib folder will be removed, if you call “mvn clean …” on the widgetset bundle. So it might be a good idea to create a folder called superDev-lib directly in the widgetset bundles root and copy the jars from${}/superDev-lib” to this folder manually.

Run the build with “mvn clean verify -f pom-superdev.xml”

4 Create a superDev launch config

The superDev launch config is a simple java launch config.


  • Main class:
  • Program arguments: “-logLevel DEBUG org.semanticsoft.vaaclipse.widgetset.DefaultWidgetset”
  • VM arguments: “-Xss8M -Xmx512M -XX:MaxPermSize=512M”

5 Enhance the classpath of the superDev launch config

The jar files downloaded under 3) need to be added to the classpath of the launchconfig.

  • Open the launch config, switch to tab “Classpath”
  • Press “Add JARs”
  • Then add all jar files located in /superDev-lib to the classpath.
  • Then add any “local client-side bundles” contained in the workspace
  • Add the source folder of the “local client-side bundles” too
  • Add the “widgetset bundle”
  • Add the source folder of the “widgetset bundle”
  • Ensure that the “local client-side bundles”, the “widgetset bundle” and their source folders are at the beginning of the classpath.

Follow the launch configs contained in Vaaclipse widgetset as a sample.


6 Run the superDev launch config

Running the superDev launch config means that the widgetset is compiled.

If the code server could start properly, you will find following lines in the console:

The code server is ready.
Next, visit: http://localhost:9876/

7 Start the application launch config

Now you need to start you application using a launch config. No special configs are required there.

8 Open http://localhost:9876/


Just follow the instructions on the website and bookmark the two links.

9 Open application in superDevMode

To do this, open {URL}/?superdevmode in your Chrome browser.

The browser will tell you that the widgetset is being recompiled. Afterwards, the application opens.

10 and 11

No steps to describe here …

12 Open source code in Chrome browser

Open the developer tools in Chrome. Under the source tab you should find all your client-side Java code.


You may set breakpoints to the code and do all the debugging stuff — right in your browser!

OSGi and Vaadin – Using ClassResource

June 18, 2015

Using Vaadin’s ClassResource in OSGi environments is pretty straightforward. But you have to know a few basics about the OSGi class loader:

In OSGi, every bundle has its own classloader. And all resources contained in a certain bundle are loaded by this bundle’s classloader only.


For instance, we try to load an image based on Vaadin’s ClassResource.

new Image("Bundle2 exported", 
        new ClassResource(, 

The ClassResource internally will call

 whenever ClassResource#getStream() is called.

The OSGi classloader takes over

After this, the OSGi classloader comes into play. It uses a defined strategy to look for the resource:

  1. If the package starts with “java”, then the request is forwarded to the parent classloader
  2. If the package is in the list of “boot delegation”, the the request is forwarded to the parent classloader
  3. The request is forwarded to “class loading hooks”
  4. The classloader checks whether there is a “import package” for “”.
    1. If so, then the resource is loaded from this imported package (meaning that the request is forwarded to a different bundle classloader). If a package could be found, the lookup will terminate.
    2. If not, proceed with 5.
  5. The classloader checks all “required bundles” whether the resource can be found there.
  6. The classloader checks the “local” resources contained in the classloaders bundle.
  7. The classloader checks the “fragments classpath” resources contained in the fragments.
  8. The classloader checks for “dynamic imports”.

How not to: Something that will never work

Assume we have two bundles.

Bundle A – contains the Vaadin-Servlet, the resource handler and all that stuff required to run Vaadin in OSGi.

Bundle B – just another bundle. “Bundle A” does not have a dependency to “Bundle B”.

Bundle B contains an image and it should be loaded by a ClassResource. If you prepare a ClassResource for the image contained in “Bundle B”, but you do not pass a class contained in “Bundle B” to the ClassResource, OSGi is not able to load the image.

new Image("", 
        new ClassResource("ImageInBundleB.png"))

The reason is that ClassResource internally will use the classloader of the UI class. And this one does not have a dependency to “Bundle B”. And so the resource can not be loaded because it is not visible to the classloader.

Using a BundleResource

I prepared a BundleResource prototype. It is licensed under the Apache License and is available at the Lunifera github repo.

new Image("", 
        new BundleResource(theBundle, 

The path to the resource is the path relative to the bundle. In this sample, the “ImageInBundleB.png” is located in a folder called “resources”.

Feel free to use the BundleResource for your own projects.


If a resource could not be found by the “ClassResource”, one just has to debug the OSGi classloader. If you are using Equinox, take a look at

org.eclipse.osgi.internal.loader.BundleLoader. It is responsible to load the resource.

Eclipse DemoCamp “Mars” Vienna

May 18, 2015

Lunifera GmbH and IoT-Vienna are organizing the Eclipse-DemoCampMars” on 19.6 2015.

With this event, we want to bring people and companies together to share their knowledge, experience with and about Eclipse. This meeting includes six Talks and a quick intro on the Eclipse Foundation’s role by Benjamin Cabé.


  • Tom Schindl: Something cool TBD
  • Werner Keil: Energie Sparen präzise Messwerte bei SmartHome und SmartGrid
  • Philip Langer: EMF Compare
  • Benjamin Cabé: IoT Talk
  • Florian Pirchner: OSGi-IoT-Vaadin

We also provide catering, drinks, beer and cakes as usual.

For details please visit

Hope to see you at the DemoCamp “Mars” Vienna…

the DemoCamp organizers

IoT: Industry 1.0 meets Business 4.0 — with Eclipse Paho

May 7, 2015

On the 9th of April (the “Global IoT Day”), we (Lunifera GmbH) co-organized a free IoT event in Vienna. With over 400 attendees, the Global IoT Day Event was a huge success — one of the biggest IoT events worldwide!

But we not only took part in the organization and hosting of this awesome event: Of course, we just had to do a small demo project and present it — the Lunifera steam engine.

“Industry 4.0” is one of the hottest topics at the moment: The computerization of production processes and the use of connected intelligent devices in production seems to be the future of industrial production. Industry 4.0 will change the way we produce (and use and scrap and recycle) things profoundly. With this “fourth industrial revolution” gaining speed, we at Lunifera GmbH have been toying around with various ideas and concepts of integration between physical world, production and business processes and user interface for some time.

Our newest proof-of-concept project in this area is our steam engine (looking back to “Industry 1.0” that brought the use of steam engines): We bought a working toy steam engine, hooked up sensors to it and set up circuitry (using, among others, an Arduino Uno and a Raspberry Pi) that converts the sensor output to binary data. Then we use the Python incarnation of Eclipse Paho in order to transfer the measurement data across any networks so it can be used pretty much anywhere.

Our steam engine: Heating the water in the boiler causes the pressure to rise (pressure sensor: top right). The steam is used to turn the wheel in the back (cyan rotation sensor above wheel). The temperature is measured by a PT1000 sensor (left side of boiler).


The sensors turn the values of physical properties into voltage levels. We read these voltage levels and convert them into binary data.

Our next step was to transmit the pressure, temperature and RPM values that we measured from the physical engine to any listeners. According to our experience in the IoT area, the most flexible, reliable and easy-to-use solution for this is MQTT. Thus, we set up an MQTT broker and two MQTT clients (one client on the Raspberry Pi that gathers and interprets the measurement data, one on the machine with the business application). Using Eclipse Paho (the Python version on the Raspberry, the Java version on the PC), it took us about three minutes to set up the desired communication.


The push-based communication in our demo project: Sensors S1 to S3 collect data, the Raspberry Pi interprets the values and transmits them to the MQTT broker. Whenever a new value arrives at the broker, it is forwarded to the other client that has registered before.

For our demo purposes, we integrated the measurement data into a simple web-based business application: We displayed the data right inside a business app by using Vaadin UI elements (various charts). In the future, it would be quite easy to integrate the values into additional complex representations such as augmented reality and so on.


In our simple example, the measurement values are displayed in a web-based demo application. Integration into standard business applications and web pages would be straightforward.

Vaadin & OSGi: managing the classloader

April 30, 2015

If you are using Vaadin with OSGi, you need to be aware of an issue related to

Vaadin changed the classloader that is used to load the UI-class. Before this change, the UI-class was loaded by the classloader of the servlet class. Now the “context class loader” is used to load it.

So if you define your UI-class in the VaadinServlet by annotation, you will get a ClassNotFoundException.

It is pretty easy to fix that issue. The solution is to define the proper classloader in ServletService. Afterwards the UI-class can be loaded properly again.

@VaadinServletConfiguration(ui = ECViewSampleUI.class, productionMode = false)
public class SimpleVaadinServlet extends VaadinServlet {
	protected VaadinServletService createServletService(
			DeploymentConfiguration deploymentConfiguration)
			throws ServiceException {
		// see
		ServletService service = new ServletService(this,
		return service;

This snippet shows an implementation of VaadinServlet.

It is used to

  1. define the UI-class by annotation
  2. create a custom VaadinServletService to define the proper classloader.


public class ServletService extends VaadinServletService {

	public ServletService(VaadinServlet servlet,
			DeploymentConfiguration deploymentConfiguration)
			throws ServiceException {
		super(servlet, deploymentConfiguration);

	public ClassLoader getClassLoader() {
		// return the bundle classloader
		// see
		return ServletService.class.getClassLoader();

The highlighted lines in the ServletService ensure that a proper class loader – the classloader of the custom ServletService – is used to load the UI-class.

Things should work properly afterwards …


Florian Pirchner

OSGi, Vaadin and Apache Bean Validation (JSR303)

March 18, 2015

Today I integrated javax.validation into Vaadin. Vaadin offers built-in support for it. But since I am using OSGi, I had to do it a bit differently.

The idea was the following:

  1. register an instance of javax.validation.ValidatorFactory as an OSGi service
  2. write a Vaadin Validator that will consume this OSGi service

And it was pretty fast. It took me about 30 min and I was done:

javax.validation.ValidatorFactory as an OSGi service

Therefore I have created a bundle org.lunifera.runtime.jsr303.validation, put in an activator and registered the OSGi service.

public class Activator implements BundleActivator {

	private ServiceRegistration<ValidatorFactory> registry;

	public void start(BundleContext context) throws Exception {
		// provide the bean validation factory
		ValidatorFactory avf = Validation

		registry = context.registerService(ValidatorFactory.class, avf, null);

	public void stop(BundleContext context) throws Exception {
		if (registry != null) {
			registry = null;


Prepare VaadinBeanValidator

Vaadin comes with a implementation for JSR303 (bean validation) called BeanValidator. Since it is licensed under the Apache License v2, I copied the validator and changed the way how the implementation will get access to the validation factory.

// access the OSGi service registry to get an instance of ValidatorFactory
BundleContext context = FrameworkUtil.getBundle(BeanValidationValidator.class)
ServiceReference<ValidatorFactory> ref = context.getServiceReference(ValidatorFactory.class);
javaxBeanValidatorFactory = context.getService(ref);

It was really fast and straightforward to combine Vaadin and OSGi for javax.validation.

Available by P2

If you would like to use the org.lunifera.runtime.jsr303.validation bundle, it is available the Lunifera P2.

The feature is called org.lunifera.runtime.jsr303.validation – Lunifera runtime: javax.validation ValidationFactory provider. And it is licensed under the EPL Eclipse Public License v1.

So feel free to use it…

redVoodo – a good idea to use eclipse databinding

June 29, 2011

Actually i am writing the UI controllers which are connecting the redVoodo UI model with the UI parts that are responsible to visualize the model. After a sleepless night i decided to refactor the whole controller code. The problem was that i had to implement tons of observing code which observes the UI model for a few nodes and causes the UI parts to reflect these changes immediately. Of course, this solutions would have worked really well, but i did not like the way how this solution works.

In this blog i am going to describe why i decided to use eclipse databinding and show some code.

The UI model

RedVoodo offers a functionality called scoped actions and menu items. See post redvoodo-scoped-actions-and-menu-items

Based on this feature actions and menu items are hidden if they are not in the scope of the active framework or sub application. For instance, an action called “delete Item” will only be visible in the “Item Subapplication” but will be hidden for the “Customer Supapplication”. These actions and menu items have “subapplication scope” which means, that they are only visible if a defined sub application is active. But there are also “framework scoped” actions and menu items. Their visibilty depends on the active framework like Sales, Inventory,…

If you want to write an application which tracks the currently active subapplication or framework, perhaps you have to write tons of code if the underlying UI model has a deep structure.

This class diagram shows a simplified version of the redVoodo UI model. The root element of the model is called YUiModel. It can contain exactly one YApplication which is an abstraction of the vaadin application. The YApplication contains many YFrameworks (like Sales, Inventory,…), but only one YFramework can be active at a time. Based on the active framework, different sub applications are shown. So each framework has its own set of YSubapplications. For instance, the framework sales could contain sub applications like Customers, SalesCampains,…

The application, each framework and each sub application can contain their own set of actions. Depending on the active framework and the active sub application, different actions should be visible at the UI.

This image shows what i am talking about:

If the sales framework or a different sub application would be selected, completely different actions and menu items would be shown.

The model shown above is an EMF model. But since redVoodo should be a very extendable framework, using EMF is the default implementation. The core of redVoodo does not have any dependency to EMF. Instead it has a dependency to model controllers. These controllers are called edit parts. The UI parts like the “framework switcher” or the “sub application tree” are using these edit parts to visualize the model but do not have a dependency to the underlying model. So everybody can easily change the default implementation and provide edit parts that are based on a JPA implementation or edit parts that are even hardcoded.

The problem

Yesterday i started to write a lot of code to observe the ui model. I had to fetch the RootModelEditPart which represents YUiModel.

  • I registered a listener at the RootModelEditPart which will be notified if the active application changes.
  • Then i implemented the same issue for the active application and added a listener to the active application which becomes notified if the active framework changes.
  • Then i added a listener to the active framework which becomes notified if the active subapplication changes.
  • Then i added a listener that becomes notified if actions are added or removed.
  • Then i started to handle many different constellations based on parts that become active and deactive.
    • Remove listener from the lower containment structure
    • Switch the parent
    • Add the listener again to the lower contaiment structure
  • Then i detected that each UI part has a different behaviour to the observables. The SubApplicationTabBar has to observe the OpenSupApplications-reference from YFramework too.
  • Then, at 10 p.m. i thought -> Hmmmmmmmmmm, what a boring job!

After a sleepless night, i took all the controller implementations and put it to trash since eclipse databinding can do all that stuff for me. I can heavily reduce the amount of required code and safe a lot of time.

The (really easy) solution

// 1. define a nested property
// 1. define a nested property
String nestedProperties =

// 2. create the observable model value
IObservableValue modelOV = BeansObservables.observeDetailValue(
	new WritableValue(rootModel, IRootEditPart.class),
	nestedProperties, ISubapplicationEditPart.class);

// 3. create the observable target value
IObservableValue targetOV = PojoObservables.observeValue(
	ActionbarPart.this, "subapplicationActions");

// 4. bind model to target
subapplicationActionsBinding = dbContext.bindValue(targetOV,
  modelOV, new UpdateValueStrategy(
  new UpdateValueStrategy(UpdateValueStrategy.POLICY_UPDATE)
	.setConverter(new NotNullConverter()));

1. define a nested property

This nested property will be splitted by the “.” and the reference path starting at the IRootEditPart will be followed for each property.

// "application.activeFramework.activeSubapplication.actions"
// "application.activeFramework.activeSubapplication.actions"
// can be visualized as:

The property “actions” inside the “activeSubapplication” will be observed. Every time it changes – nevertheless why it changes (due to a change of active framework or something) – we are becoming notified.

So we do not have to implement that boring listener hierarchy as described under “the problem”.

2. create the observable model value

Creates an IObservableValue which represents the “actions” property inside the “activeSubapplication” inside the “activeFramework” inside the “application”

3. create the observable target value

Addresses the property “subapplicationActions” of this instance (ActionbarPart.this). Every time the “actions” from “activeSubapplication” changes, the setter this#setSubapplicationActions(IActionEditPart editPart) should be invoked.

4. bind model to target

Therefore the DatabindingContext is used to bind the ObservableValues (model and target) to each other.

And here you can see the implementation of the setSubapplicationActions-method. It stores the subapplicationActions and puts it to the UI.

 * Sets the list of subapplication actions.

 * Called by databinding.
 * @param subapplicationActions
 *            the subapplicationActions to set
public void setSubapplicationActions(
		List subapplicationActions) {


That’s all i had to write to observe a nested property inside my model tree.

I hope you can see the big advantage of eclipse databinding too and hope you give it a try.

Additional informations

Eclipse databinding

redVoodo – scoped actions and menu items

June 27, 2011

As described in my last post, redVoodo is a project which target is to provide an environment that supports a developer to write business applications on a very quickly and easy way. A lot of base functions like selection support, lookups,… should be provided by the framework itself.

Also the scoping of actions and menu items should be handled by redVoodo and no additional code should be required for this issue.

Scoping of actions and menu items means, that only actions and menu items that are in the scope of an active ui part should be visible. If the active ui part changes, also the visible actions and menu items should be adjusted to the current active part. In order to avoid confusion of users it is good practice to hide actions which are not required right now.

This image shows what i am talking about. The “purchasing (scoped) actions” and the “purchasing (scoped) menu items” are only visible if the purchasing framework is active.

For instance, if the inventory framework is active, no scoped actions and menu items are available. See next image.

Of course, scoping is not limited to frameworks. Also active applications can cause actions and menu items to become visible.


My current solution is well grounded and based on EMF (eclipse modeling framework). The ui is abstracted by an EMF metamodel. Instances of this metamodel (ui models based on this metamodel) are used by the core runtime to build the ui. States like active framework, active subapplication, open subapplications,… are stored in this model.

Additionally a “selection support OSGi service” was implemented. Ui parts are using the selection support to observe active ui model controller like “active framework controller” and “active sub application controller”. Based on the selections and the ui EMF model the parts are adjusting the actions and menu parts.

Since the ui is based on an EMF model I am going to write a Xtext grammar in a few week which allows the developer to define the ui model on a very very comfortable way.

Further it should be also possible to use the redVoodo Xtext grammar to change the ui during runtime.

  • open an redVoodo grammar editor in eclipse
  • connect to a running OSGi server
  • open the currently used ui model
  • modify the ui at runtime
  • changes are immediatelly pushed to the ui

This implementation is a well grounded default. But since redVoodo offers a really extendable API everybody can easily write its own implementation.

The sourcecode will be available in about 2 – 4 weeks.


I have prepared a movie which shows how actions and menu items are hidden and showed again based on an active ui part. I hope you enjoy the movie.
Direct link to the movie:

Additional information

If you are interested in redVoodo just follow our blogs and website.

redVoodo EOS – early results

June 9, 2011

I am very happy to present the early results of redVoodo EOS.

EOS is a independent part / component of redVoodo.

It will become a project which offers a lot of base functionality for web based business applications like ui layouting, selection support, business drag and drop, multi tab enablement and many more very useful features. It will be highly extendable by the use of OSGi services and can be customized to any requirements.

Today i finished some very important steps.

  • Selection support
  • Multi browser tab functionality
  • UI elements contribution services
  • Active part set management
  • ICEPush for many browser tabs

Right now some basic ui element prototypes like a framework switcher have been finished. It is provided by an OSGi service which can be stopped and started at runtime. Stopping a bundle means, that the ui element is removed from the available elements immediately. Starting the bundle provides the element to EOS again.

Additionally the state of the ui elements is completely decoupled from the ui and is stored in an EMF (Eclipse modeling framework) model. So the state can be restored every time an “ui element contribution OSGi service” like the “framework switcher” is started.

But you can store the state in your preferred way. EMF is only a default implementation –> redVoodos basic statement “convention over configuration”.


I hope you enjoy this movie which demonstrates the result of starting and stopping bundles and restoring ui states.
Direct link to the movie:

Additional information

If you are interested in redVoodo just follow our blogs and website.

Vaadin OSGi ICEPush Services

May 8, 2011

1. Introduction

About 4 years ago i started working with OSGi, but this is the first project i am using declarative OSGi services. The concept of OSGI allows to build very extendable and loose coupled software environments. In particular the use of OSGI-services is very important to create some kind of plugin architecture which allows to provide functionality on a very flexible way.

OSGi and vaadin

So far web applications did not support these concepts very well. Some time ago Chris Brind, Neil Bartlett and Peter Kriens have written different vaadin OSGi integrations which make it possible to run vaadin inside an OSGi container. (See blog from Chris Brind: Comparing approaches to vaadin and OSGi)

Vaadin is a framework to build web applications based on java code. It uses GWT (google web toolkit) to render the UI elements and offers serversided counterparts to the client UI widgets. A really amazing framework to build high level web UIs.

Kai Tödters vaadin demo app

The vaadin OSGi implementation from Chris Brind was used by Kai Toedter to write his amazing vaadin application based on OSGI-services. Using the “whiteboard pattern”, OSGi-services that are used to provide UI elements like Actions and Components are injected into the com.vaadin.Application. With this approach Kai could build a very loose coupled application environment. The UI elements “contributed” to the application depend on the installed and started OSGi-bundles.

Basically Kai’s vaadin application can be divided into two different parts:

  1. The main bundle with its main application that requires OSGi-services to build the UI.
  2. Contributor bundles providing services required by the main application.

The main bundle defines the layout of the main application but there is no knowledge about the exact content of the application involved. The content is provided by “contributor bundles” and may contain Actions, Buttons or Views as some kind of vaadin.Component.

This image displays Kai’s demo application. All shown bundles contain OSGi-services that are used to access the UI-elements. As an example the red arrows are pointing to the provided UI elements.

The next image gives you a summary about the bundle dependencies. To keep things simple, we only consider the IViewContribution service. IActionContribution works nearly the same way.

The main bundle requires IViewContribution services which offer access to the UI elements that should be added to the user interface. The interface IViewContribution will be implemented by classes located in different bundles. The OSGi-service-component-runtime observes starting and stopping bundles and injects the upcomming services into the bound MainApplication. Bindings are defined in the service component definition.

Service component definition:

Contribution to Kai’s demo application

At the end of this blog i am going to tell you, how applications can be push enabled automagically. All you have to do is to install and start a couple of bundles and all vaadin applications have the capability to become pushed.

Therefore we have to enhance Kai’s application by a provided interface called IApplicationProvider.

public interface IApplicationProvider {

* Returns the provided application.
* @return
Application getApplication();


That interface returns an instance of the application associated with this applicationProvider.

Additionally we let Kai’s application implement that interface and return “this” as the reference.

public class MainApplication extends Application implements
IApplicationProvider {

public Application getApplication() {
return this;

No we are going to provide the MainApplication.class as an OSGi-service for the interface IApplicationProvider.

Each time a new application was created by the component factory, then service components which reference this interface will be called.

2. Services come and services go

Before i start writing about the vaadin osgi push service, i’d like to talk about the flexibility of OSGi-services.

People already using OSGi know that bundles have a lifecycle. They can become installed, started, stopped,… into a running OSGi container without the requirement of restarting the container. A very flexible way of providing functionality.

Of course, if a bundle contains OSGI-services and the bundle was started a new service is offered by the framework. If the bundle becomes stopped, the service will be deregistered from the OSGi-runtime. It would be good practice to handle this flexibility inside your applications if you are using OSGi-services. Of course you can assume that services are static, but if you don’t so, then your application should be designed to handle the lifecycle of bundles.

Referring to Kai’s application this would imply that stopping a service bundle (a yellow one from image above) will remove all UI contributions like actions, menu bar actions and views associated with this bundle from the UI. You can use Kai’s “bundle view” to demo this issue.

Stopping or starting a bundle like “” will remove a service from the main application which reflects the changes immediatly and updates the UI. The menu bar action and the button “print” will be removed.

OSGi management console

Kai used the client UI of his application to control the lifecycle of bundles, but OSGi offers another way. You can use the OSGi management console. The commands “start bundleNumber” and “stop bundlenumber” will start and stop these bundles.

But if you are using the management console with Kai’s application, a starting or stopping bundle will not update the UI immediately since the server cannot notify the UI about this change! So you have to wait for the next UI refresh until the client UI has reflected the stopped bundle.

This image displays the problem using the management console to control the lifecycle of bundles. If a bundle becomes stopped, the serversided components get a dirtyState, which cannot be pushed to the client!

The changes will be transfered to the client at the next client UI refresh. Since vaadin clients are not pushable without using any addons, the server cannot inform the client about changes.

But vaadin offers an addon called ICEPush. ICEPush allows the client UI to be notified by the server on changes. A really helpful addon which perfectly matches the requirements described above.

3. Details about the implementation

This chapter of my post gives you an introduction how i have implemented ICEPush using the vaadin OSGi integration from Chris Brind.

Main goal was to provide bundles which enable the ICEPush addon and the “vaadin OSGi ” addon at the same time. And to push changes from the server the client UI in OSGi environments.

Main issue

ICEPush and vaadin-OSGi both provide their own servlet.

  • ICEPushServlet is responsible to serve the ICEPush javascript code and to handle requests ending with “.icepush”
  • VaadinOSGiServlet is responsible to create a new instance of com.vaadin.Application based on an OSGi-ComponentFactory


Since exactly one servlet is required for my issue i decided to merge the contents of both servlets and to create a new one called ICEPushVaadinOSGiServlet. Luckily both implementations are based on the “Apache License 2.0” license and so it was legal to combine them.

The ICEPushVaadinOSGiServlet offers a compound functionality as ICEPushServlet and VaadinOSGIServlet do.

This code displays a stub of the new servlet class. At the beginning of the method stub you can see where is it original from.

* Merges org.vaadin.osgi.VaadinOSGiServlet (vaadins osgi addon) and
* {@link org.vaadin.artur.icepush.ICEPushServlet} (vaadins icePush addon).
public class ICEPushVaadinOSGiServlet extends AbstractApplicationServlet {

// from org.vaadin.osgi.VaadinOSGiServlet
protected Class<? extends Application> getApplicationClass()
throws ClassNotFoundException {
return Application.class;

// from org.vaadin.osgi.VaadinOSGiServlet
protected Application getNewApplication(HttpServletRequest request)
throws ServletException {
// ...

// from org.vaadin.artur.icepush.ICEPushServlet
public void init(ServletConfig servletConfig) throws ServletException {
// ...

// from org.vaadin.artur.icepush.ICEPushServlet
protected void service(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
// ...

* Sends the ICEPush javascript code to the client.<br>
* from org.vaadin.artur.icepush.ICEPushServlet
* @param request
* @param response
* @throws IOException
private void serveIcePushCode(HttpServletRequest request,
HttpServletResponse response) throws IOException {
// ...

* Track the component instance and session. If this is disposed the entire
* associated http session is also disposed.<br>
* from org.vaadin.osgi.VaadinOSGiServlet
class VaadinSession {
// ...


The VaadinOSGiApplicationManager is the main class of the vaadin OSGi integration. It runs as an OSGi component and is responsible to create and register a servlet at the http service. In the org.vaadin implementation the VaadinOSGiServlet is used.

I  enhanced this manager and added a required OSGi-service (interface == IServletFactory ) which provides a HttpServlet. With this approach the used servlet is very loose coupled and can be provided by OSGi-services. The service has to provide an implementation of the IServletFactory which creates new instances from a http servlet.

* A factory provided by OSGI-Services to contribute servlets.
public interface IServletFactory {

* Returns a servlet to be used by the {@link VaadinOSGiApplicationManager}.
* @param factory
*            which has create the {@link Application}
* @param servletpath
*            which is used to register the servlet
* @param initialProperties
*            Properties registered against the component factory.
* @return
HttpServlet createServlet(ComponentFactory factory, String servletpath,
Map<String, Object> initialProperties);


4. Vaadin OSGi Push Addon bundles

The original VaadinOSGiApplicationManager was copied since i did not want to change the “none pushing osgi vaadin” implementation from Chris Brind and have created a new bundle called org.vaadin.pushosgi.

This bundle is replacing the org.vaadin.osgi bundle and contains the VaadinOSGiApplicationManager including the extended IServletFactory functionality.

As you can see, no servlets are contained in the bundle. Since the servlets are provided by OSGi-services, they are defined in different bundles.

The next image displays two servlet contributor bundles which offer OSGi-services.

With this approach you only have to decide which servlet should be used and to install the prefered bundle into the target platform. No further steps are required. The dependencies between the OSGi bundles and services will be resolved by the OSGi framework and the installed servlet will be used automatically.

That image displays a summary about the bundles involved.

ICEPush implementation

If you are using the ICEPush addon by Artur Signell you have to install the ICEPush addon. It is divided into a server side and a client UI part.


All required java code for the server side is contained in the bundle “org.redvoodo.vaadin.addon.icepush“. No changes have been made to the sourcecode. Just an OSGi-bundle has been created from the ICEPush-jar-files.

Client UI

Using vaadin all client side addons have to be compiled at once. The resulting widgetset has to be provided as described in The example from this post uses the widgetset from bundle-fragment “org.redvoodo.extension.ct.osgi.widgetset.fragment“.

The widgetset has been speficied in the launch configuration:


Minimal bundle requirement

If you want to use the vaadin OSGi ICEPush, you have to install a minimal set of bundles:

  • org.vaadin.pushosgi – the main bundle which contains VaadinOSGiApplicationManager
  • org.redvoodo.addon.osgi.push.servlet – provides the ICEPushVaadinOSGiServlet
  • org.redvoodo.vaadin.addon.icepush – server side java classes from ICEPush
  • some fragment bundle like org.redvoodo.extension.ct.osgi.widgetset.fragment containing the compiled widgetset

Thats all you have to add to your OSGi launch configuration to have a properly configured “vaadin OSGi pushable application”.

But there is no further support. You have to handle the ICEPush yourself.

pusher = new ICEPush();

// doing the push


This movie demos what i was writing about so far:

5. redVoodo Push Services

So far you can use ICEPush in vaadin OSGi applications. But there is no further support for some kind of “OSGi push services”.

Therefore i have prepared a set of very flexible and loose coupled bundles which offer “OSGi push services” and help you to manage your pushing applications.


  • – The service interface definition
  • – Provides default implementation for IPushService
  • – Provides default implementation for IPushServiceManager
  • – Provides default implementation for IManagedPusher
  • – The queen of this addon. Bridges IApplicationProvider and IManagedPusher

Lets start with the service interfaces:

The main interfaces of these services are IPusher and IPushService:

public interface IPusher {

* Forces a push to the client. If the pusher is not active, a call to
* this method must not result in an error.
* @return true if the push was successful. False otherwise. If the pusher
*         was not active, false will be returned.
boolean push();

* Returns the application the pusher is prepared for. Or <code>null</code>
* if the pusher is a compound pusher which pushes several applications.
* @return
Application getApplication();


The IPusher is responsible to push changes to the client. Each pusher is associated with exactly one Application.

* A push service is used to notify the client, that it should refresh its
* state.
public interface IPushService {

* Activates the push functionality for the given application and ensures,
* that the pusher for this application can be accessed by this service.<br>
* The acitvated pusher will be stored in this service until deactivate
* pusher is called.
* @param application
* @return
IPusher activatePusher(Application application);

* Deactivates the push functionality for the given application. Further
* calls to a pusher associated with this application will result in an
* error.
* @param application
* @return
void deactivatePusher(Application application);

* Deactivates the push functionality for the application associated with
* the given pusher. Further calls to pusher associated with this
* application will result in an error.
* @param application
* @return
void deactivatePusher(IPusher pusher);

* Returns a pusher which pushes all applications that are registered within
* this pushService.
* @return
IPusher getGlobalPusher();

* Returns a pusher for the given application.
* @param application
* @return
IPusher getPusher(Application application);

* Returns a compound pusher based on the scope. The scope allows to collect
* pushers which are registered within this pushService.
* @param scope
* @return
IPusher getPusher(IScope scope);

* Scope is used to create a compound pusher based on other pushers.
public static interface IScope {

* Returns a compound pusher which delegates the push call to the
* contained pusher.
* @param pushers
* @return
IPusher getPusher(Map<Application, IPusher> pushers);


The IPushService is responsible to activate and deactivate pusher for their associated Application and to access them.

Since IPushService is an OSGi-service, you have to handle the lifecycle of that service. See chapter “services come and services go”.

ATTENTION: Bundle was removed with 0.7.2. Was not an OSGi like approach.

ATTENTION: In Version 0.7.1 this bundle was named

This image is a summary about the service and its default implementation.

The bundle can be used as a default implementation of the push service. But you can write your own implementation and provide it as a service.

Was added with 0.7.2

The image shows a summary and the default implementation of the IPushServiceManager. The PushServiceManager is responsible to manage IPushServices. It allows clients to register listener and to observe the services and their lifecycle.

The bundle can be used as a default implementation of the IPushServiceManager. But you can write your own implementation and provide it as a service.

Was added with 0.7.2

To hide the lifecycle of IPushService and IPushServiceManager, i have prepared an interface which describes some kind of a helper class.


It internally uses the IPushServiceManager and IPushService, but hides the lifecycle handling from the developer. If services come and services go, the ManagedPusher does not have to be refreshed externally. All the refreshing stuff is handled internally.

A very useful class to minimize the amount of effort required to use the redVoodo push services.

The component factory can be required as any OSGi-service. But you have to specify the target of the requirement.


Code samples how to use the service:

* Called by the OSGi framework
public void bindManagedPusherFactory(ComponentFactory pusherFactory,
Map<String, Object> properties) {
      this.pusherFactory = pusherFactory;

* Called by the OSGi framework
public void unbindManagedPusherFactory(ComponentFactory factory,
Map<String, Object> properties) {
      this.pusherFactory = null;

// to create a new pusher
IManagedPusher pusher = (IManagedPusher) pusherFactory.

// to dispose the pusher

For details how to use see class

This bundle is a really important bundle for the vaadin OSGi push services addon. It bridges the IApplicationProvider and the IManagedPusher. Installing this bundle into the target platform will automatically enable push for all applications provided by IApplicationProvider.

The bundle requires the IApplicationProvider OSGi-Service. Each time a new application was created by the component factory, the service component will be notified about the new application and uses the ComponentFactory to create an instance of IManagedPusher. The managed pusher itself handles the registration at the IPushService. If the application is destroyed the service component will also be notified and the pusher for the destroyed application will be removed.

Additionally this class requires the componentFactory-service. If a new ComponentFactory for IManagedPusher became available, the class will handle this notification. If no factory was installed yet, nor of the applications are push enabled. But an upcoming component factory service causes the bridge to create new instances of IManagedPusher for each application. And so all applications become push enabled.

Referring to Kai’s demo application, only one change had to be made to his application. The IApplicationProvider was added to the vaadin.xml compontent definition as a provided service. But his application does not have any dependency to the redVoodo push services. Immediately after the instantiation of an application by a component factory, the application becomes push enabled automatically.

The push to Kai’s application is triggered by the bundle “” (All org.redvoodo.extension.ct.osgi bundles are extensions of Kai’s application). Since this bundle requires the IPushServiceManager service, it has access to all registered push enabled applications and can use that service to push all applications. (Remember: The applications have been registered at the pushService by the ManagedPusher above).

String symbolicName = event.getBundle().getSymbolicName();
if ((symbolicName.startsWith("")
|| symbolicName.startsWith(""))
&& !((symbolicName.contains("main")
|| symbolicName.contains("theme")
|| symbolicName.contains("bundleview")
|| symbolicName.contains("logback")))) {
       // push all registered clients

If a bundle becomes started or stopped, the bundleChanged event will be called. For specified bundles the AppPusherPlugin#pushAll() method will be called, which pushed all dirty states to the client.

How to use push services

There are several ways how redVoodo push services can be used.

Require a service

Require a service like IPushServiceManger, IPushService or IManagedPusher. Depends what the service will be used for.

Use the default implementations

Provided by bundles:


Write your own services

Feel free to write your own services and to provide them as a service.


I hope this blog post could give you an introduction about the redVoodo OSGi ICEPush services. If you have any suggestions it would be really nice if you may write a comment.

Thanks a lot to Kai Tödter, Chris Brind, Neil Bartlett and Peter Kriens for the really great available code and blog posts how vaadin OSGi integration can be implemented.

Further informations

In bed with vaadin and OSGi by Chris Brind

Dynamic modular Web Applications with Vaadin and OSGi by Kai Tödter

OSGi vaadin integration by Peter Kriens

blog by Neil Bartlett

blog by Ekkehard Gentz

how to use vaadin and OSGi from redVoodo

how to use vaadin addons from redVoodo

how to push to browser from redVoodo

Comparing approaches by Chris Brind