Posts Tagged ‘Vaadin’

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.

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

Eclipse-Databinding for Vaadin

April 10, 2015

A while ago we (Lunifera GmbH) have implemented Eclipse-Databinding for Vaadin. Two different databinding approaches that perfectly work together.

In this blog i’d like to talk about the two different ways of databinding and how these worlds can be tided together.

Vaadin comes with an integrated databinding capability. Databinding in Vaadin means, that UI elements (components) are bound to so called containers, items and properties. So the data of components can be abstracted from the component itself. But Vaadin defines no common way to bind these containers, items and properties to each other.

There the eclipse databinding comes into play. Eclipse databinding provides a common way to bind so called “observable values” to each other. An “observale value” is an abstraction above the “data related to its source”. Eclipse databinding comes with an implementation for POJOs, Beans (POJOs with PropertyChangeSupport), SWT-Widgets, JFace-Components, EObjects (Eclipse Modeling Framework – EMF) and the EMF-Edit-Commands. These implementations allow you to bind “observable values” from different domains (one of mentioned implementations) to each other.

In combination Vaadin databinding and Eclipse databinding are working properly together.

Vaadin Databinding

Vaadin databinding consists of 3 concepts for different use cases:

  • Property – An abstraction for a type and value. Used to bind fields like TextField to the property
  • Item – A collection of properties. It represents a row in a table. Each property inside the item has a unique propertyID
  • Container – A collection of items. It represents a data-table. Each item inside the container has a unique itemID

Property, Item and Container are expressed by interface. And Vaadin comes with a lot of proper implementations for different usecases.


Image: “Book of Vaadin 8.1” – Copyright 2015 Vaadin Ltd [1].


// Create a property
ObjectProperty property =
    new ObjectProperty("Florian", String.class);
// Create a text field
TextField nameField = new TextField("Firstname");
// Bind nameField to data

See also: “Book of Vaadin 8.2.1”

As soon as the property is set to the field, you may use the property to read and write values.


Dealing with items is really similar to properties.

PropertysetItem item = new PropertysetItem();
item.addItemProperty("firstName", new ObjectProperty("Florian"));
item.addItemProperty("age", new ObjectProperty(36));
// create a form
Form form = new Form();

See also: “Book of Vaadin 8.3.1”

In this case an item is prepared and set to a form. Forms are special components that show defined properties of the given item.

There are different ways to define items. The example above uses a PropertysetItem which allows you to define all properties manually. But there are also more comfortable way for pojos.

// Create an instance of the bean
Person bean = new Person();
// Create a bean item configured for type Person.class
BeanItem<Person> item = new BeanItem<Person>(bean);

// Set the item to the form
Form form = new Form();

Sample: “Book of Vaadin 8.3.2”
To automatically create an item for a bean, that holds each bean-property, you just may use the BeanItem.


// set a personContainer to the table
Table table = new Table("Persons");

See also: “Book of Vaadin 8.5”

For containers there is also a generic way to define the container properties (the columns of the container). And also a lot of very useful implementations like the BeanContainer or BeanItemContainer. Based on the JPAContainer you can connect your Vaadin components to JPA really quickly.

For details about BeanItemContainer see: “Book of Vaadin 8.5.4”

Eclipse Databinding

The Eclipse databinding follows a more general way and tries to abstract bindings in general.

Unbenannte Zeichnung (1)If you would like to use Eclipse databinding, you have to deal with some concepts.

  • ObservableValue (ObservableList) – it is defined by an interface and is an abstraction above a data-endpoint.
  • UpdateValueStrategy – defines how source-to-target and target-to-source updates will be processed.
  • Binding – binds the observable values (or lists) to each other. BindingStrategy can be used.
  • DatabindingContext – It is a common state for all contained bindings.
  • Realm – It is responsible to synchronize updates with the environment

Observable Values

Similar to the Vaadin databinding, an obervable value defines the type and value the instance deals with. The observable value knows how to access the underlying “target-element”. This “target-element” may be anything, as far there is an implementation for it. For now the”target-element” may be a pojo, a bean, an EObject, a SWT-widget,… The observable value will register all required listeners at the “target-element” to get notified about changes. If the value of the “target-element” is changed, then the “obervable value” will notify the Binding, which updates the value at the opposite side of the Binding.


The UpdateValueStrategy may be used to define how values are updated.They can be defined for “source-to-target” and “target-to-source” updates. The UpdateValueStrategy is also responsible for data conversion.

It comes with 3 policies:

  • POLICY_NEVER – Values in the “observable value” will never be transferred to the opposite end of the binding.
  • POLICY_ON_REQUEST –  Values in the “observable value” will only be transferred to the opposite end, if requested by a method call.
  • POLICY_UPDATE – If the “observable value” becomes notified about changes in the “target-element”, then the value will be automatically transferred to the opposite of the binding.


The ValueBinding connects the Source-ObservableValue to the Target-ObservableValue according the UpdateValueStrategy-Policy. It also offers methods to validate and update model-to-target or target-to-model (Model is a synonym for Source) operations.


The databinding context manages all bindings. Also List- and Set-Bindings. The granularity about the instances of DatabindingContexts depends on the underlying application. In general i would say, that all bindings that should be validated in a common context, should be added to the sames context. If you have different views as part of your system, each view may get its own context. But it depends on you.


When you are using Eclipse databinding, you need to be aware about its lifecycle. If a view is closed, a timeout occurs,… you must ensure, that the databinding context is #disposed(). There is a method for it. Otherwise the Vaadin components will receive value updates, even if the UI is already closed.


For instance if you are doing a long running operation as an async operation in a different thread and you expect that the async operation updates your UI properly, you need a way to sync your UI with this thread. In SWT you have to update the UI in the SWT-Ui-Thread. In Vaadin you need to call UI#access(…).

The realm is specific for each databinding implementation. The source- and the target-observable-values may have their own Realm. So it would be possible to bind a SWT-UI to a Vaadin-UI. I never tried to do so, but i am pretty sure, that it will work properly.

Eclipse-Databinding for Vaadin

We have prepared an eclipse databinding implementation for Vaadin. You can find it in this github-repo. There is also a P2-Updatesite located here: Lunifera-P2-Repo.


Before you create the DatabindingContext, you need to activate the Realm for VaadinDatabinding.

// Activate the realm

// Create databinding context
DataBindingContext dbc = new DataBindingContext();

Even if you would like to add new Bindings in a different Thread, you need to activate the realm. Otherwise databinding does not know anything about the current UI-instance.

In real projects you won’t have to call the activation on certain places again and again. So there is a perfect place to do so.

You have to override the VaadinServletService and add following method:

public UI findUI(VaadinRequest request) {
	UI instance = super.findUI(request);

	// activate the realm for the current ui and thread

	return instance;

Then every time, Vaadin is looking for the current UI-instance, the realm will be activated automatically.




Now lets start with some examples demonstrating how to use the eclipse databinding for Vaadin.

1 Binding components –> #value

// Activate the realm

// Create databinding context
DataBindingContext dbc = new DataBindingContext();
// Create the Vaadin components
TextField sourceField = new TextField();
Label targetField = new Label();
// Create the observable values
IObservableValue sourceOV = VaadinObservables.observeValue(sourceField);
IObservableValue targetOV = VaadinObservables.observeValue(targetField);

// bind the values to each other
dbc.bindValue(sourceOV, targetOV);

This sample binds the value of the textField to the value of the label. If the value of the textField changes, the label is updated.

2 Binding components –> #enabledState

// Activate the realm

// Create databinding context
DataBindingContext dbc = new DataBindingContext();

// Create the Vaadin components
CheckBox checkbox = new CheckBox();
TextField textField = new TextField();
// Create the observable values
IObservableValue sourceOV = VaadinObservables.observeValue(checkbox);
// observe the enabled state of the textfield
IObservableValue targetOV = VaadinObservables.observeEnabled(textField);

// bind the values to each other
dbc.bindValue(sourceOV, targetOV);

This sample binds the value of the checkBox to the enabled property of the textfield. If the checkbox is checked, then the textField is enabled. Otherwise it is disabled.

3 Bind components to beans

// Activate the realm

// Create databinding context
DataBindingContext dbc = new DataBindingContext();

Person person = new Person();

// Create the text field
TextField textField = new TextField();

// Create the observable values
IObservableValue sourceOV = BeansObservables.observeValue(person, "firstname");
IObservableValue targetOV = VaadinObservables.observeValue(textField);

// bind the values to each other
dbc.bindValue(sourceOV, targetOV);

This sample binds the “firstname”-property of the given bean to the value of the text. If the value of the textField or the value of the bean changes, then the change is updated at the opposite site.

4 Reuse the Vaadin property

// Activate the realm

// Create databinding context
DataBindingContext dbc = new DataBindingContext();

Person person = new Person();

// Create the text field
TextField textField = new TextField();
textField.setPropertyDatasource(new ObjectDatasource());

// Create the observable values
IObservableValue sourceOV = BeansObservables.observeValue(person, "firstname");
textField.setPropertyDataSource(new ObjectProperty<String>("", String.class));

// bind the values to each other
dbc.bindValue(sourceOV, targetOV);

In this sample, an ObjectProperty was set to the textField. The Vaadin databinding implementation internally tries to get the property datasource before binding. If it is available, then the property will be bound. Otherwise the field itself is bound. So it is your choice whether you want to work with properties or not.

5 Bind the multiselection of table-1 to the input of table-2

// Activate the realm

// Create databinding context
DataBindingContext dbc = new DataBindingContext();

// Create the Vaadin components
Table table1 = new Table();
Table table2 = new Table();

// observe the multi selection
IObservableList table1OV = VaadinObservables.observeMultiSelectionAsList(table1, Person.class);
// observe the content
IObservableList table2OV = VaadinObservables.observeContainerItemSetContents(table2, Person.class);
// bind the values to each other
dbc.bindList(table1OV, table2OV);

This sample binds the multi-selection of table1 to the input of table2. So table2 shows the selected items of table1. Note, that this kind of binding uses ObservableLists.


6 Bind a table to a WritableList

// Activate the realm

// Create databinding context
DataBindingContext dbc = new DataBindingContext();

// create a table
Table table = new Table("Persons");
table.setContainerDataSource(new BeanItemContainer<Person>(
// create a writable list as model
final WritableList model = new WritableList();
// observe the table container content
IObservableList tableOV = VaadinObservables
		.observeContainerItemSetContents(table, Person.class);

// bind the lists to each other
dbc.bindList(model, tableOV);

// create a button to add records
Button button = new Button("Add person");
button.addClickListener(new Button.ClickListener() {
	public void buttonClick(ClickEvent event) {
		Person person = new Person();
		person.setName("My first name");
		person.setName2("Another name");
		person.setBirthday(new Date());

This sample binds a WriteableList as a model to the container contents. If a Person is added to the model, the table will update it’s contents.
The Button is used to add new records to the model.

7 Bind a table to a nested list in a bean or pojo

// Activate the realm

final DataBindingContext dbc = new DataBindingContext();

// create a table
Table table = new Table("Persons");
table.setContainerDataSource(new BeanItemContainer<Person>(Person.class));

// create the model
final Person father = createPerson("Father", 43);
father.addToChildren(createPerson("Child 1", 17));
father.addToChildren(createPerson("Child 2", 19));

// observe the table container content
IObservableList tableOV = VaadinObservables
		.observeContainerItemSetContents(table, Person.class);
// observe the nested children list
IObservableList childrenOV = BeansObservables.observeList(father,
		"children", Person.class);

// bind the lists to each other
dbc.bindList(tableOV, childrenOV);

// create a button to add records
Button button = new Button("Add person");
button.addClickListener(new Button.ClickListener() {
	public void buttonClick(Button.ClickEvent event) {
		Person person = new Person();
		person.setName("Child 3");
		// Update the targets

This sample binds a nested children list located in Person.class as a model to the container contents. The Button is used to add new records to the model.

Attention: If a person is added to the children list of the bean, the table is not updated automatically. This happens since the PropertyChangeSupport does not really support notifications for changed collections. So you need to call dbc.updateTargets() or binding.updateModelToTarget().
If you are using the Eclipse Modeling Framework, then also changes in Sets and Lists are automatically transferred to the table, since EMF can deal with notifications for collection changes.

Attention2: If the person bean does not provide PropertyChangeSupport, then you need to use PojoObservables#observeList to create the model observable.


With “Eclipse Databinding for Vaadin” can bind Vaadin components to other components, beans, pojos,… very quickly. The databinding implementation ensures, that values are treated properly. Using “Eclipse Databinding for Vaadin” developers can save a lot of lines of code.

See also

The examples in these additional sources may also be used for the “Eclipse databinding for Vaadin”. The core concepts are always the same.

[1]  Copyright 2015 Vaadin Ltd, licensed under a Creative Commons CC-BY-ND License version 2.0

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…

Sharky – well earned break after a hard day

September 20, 2013

After a hard day, sharky rests in our living room.

Today we wired things together properly. Using a Vaadin UI and the Mosquitto M2M server to transfer rc commands to sharky. And sharky was following them properly.

We also implemented a JUnitTest that observes ultra sonic sensors. Sharky was controlled by the integration test and had to come close to the ultra sonic sensors. Then a shark alarm was sent by beagle bone and integration test became green.

Sleeping sharky


Vaadin Web UI

For now the Vaadin Web UI is very simple. You can specify a value for left, right, dive and arise. The scaler at the right side controls the speed. And an emergency stop is implemented by “ESC”.

The alarm fence TextField specifies the minimum distance sharky may come close to the ultra sonic sensors. After falling below that distance “SHARK ALARM” is triggered.

The log table in the lower side shows all commands that have been sent to the M2M server. They will be translated into hardware GPIO outputs by beagle bone black. Beagle bone therefore uses the eclipse mihini project and a lua MQTT client.


Next steps

On monday we have the last test flight in a hall, before we are leaving to our keynote on tuesday morning.

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