Community Spotlight - August 2015

Spotlight, featured image

We skipped the July’s episode due to summer vacations, so there are a lot of community efforts in the buffer. Here is just a part of the cool stuff that has happened in the Vaadin community during the past months. We’ll get to add-on updates and other articles in the next episode.

Wajdi Almir Ahmad has written a nice tutorial to that covers using JS libraries with GWT JSNI binding and Vaadin. Although in Vaadin 7 there is also a plain JS+server side Java method to do this, which may be slightly faster to get started, this is still the way to go with non-trivial components.

SmartMeter Light is a commercial JMeter substitute. It supports load testing Vaadin applications, even without disabling XSRF protection, the infamous feature teasing load testers. Related to it, they wrote an in depth explanation of how the XSRF mechanism works in Vaadin, something you might be interested in even if you don’t need a load testing tool.

Since Liferay 7, Vaadin won’t be bundled as a part of the Liferay distribution due to architectural changes in Liferay. The bundled approach was somewhat problematic already in the past when portlets wanted to use different versions of Vaadin, so already recently we started to advocate for “self-contained packaging” of Vaadin portlets. The downside with that is a slightly increased resource usage. As Liferay 7 will be based on OSGi: you can kind of get the best of both worlds. Core Vaadin is an OSGi bundle, Vaadin add-ons can be OSGi bundles and you can build, for example, your own “vaadin-tools” bundle to be shared by all or some of your Vaadin based portlets. Sampsa Sohlman wrote a great article about his experiments with OSGi based Vaadin portlets in Liferay 7.

How many times have you written a top level “navigation framework”, with a menu or “sidebar” for switching between main views? No need to do that again, especially if you are using Vaadin Spring. Petter Holmström wrote a nice add-on for Vaadin CDI users that automatically collects the views you have annotated  to a sidebar that provides a “top level navigation”. A similar helper for CDI applications can be found from my cdi-helpers add-on. If you have any improvement ideas for either of those, let us know about them via GitHub.

Those writing GWT or client side Vaadin apps should definitely check out the new GWT with Polymer Elements tutorial by Manuel Carrasco Moñino. It uses the gwt-polymer-elements library born in our labs and it is probably the easiest way to build stuff to comply with Google’s Material Design principles in GWT applications.


Jar packaged web apps with WildFly Swarm

“Make jar, not war”

In the era of virtual servers and various cloud services, it has become common that a web server hosts only one web application. The overhead of having a separate execution environment for each web app, for both server room and maintenance people, has become so small that it often really makes sense. Applications, and especially their servers, are easier to maintain and less dependent on each other.

Having a separate application server in this kind of setup has become an overhead for the maintenance. The Spring Boot project has ignited a strong new trend in the Java web app scene, where the server is an integrated part of the deployment artifact. Applications are started with the good old public static void main(String[] args) method and java -jar myapp.jar command, which can considerably simplify both deployment and development (launching a main method is still simpler than using IDEs server integrations). “Make jar, not war”, like Josh Long from Pivotal tends to market Spring Boot.

Another advantage of this kind of Java web app packaging is that the deployment artifact may also become smaller (jar file vs. server + war file), as one can leave out features of the “application server” that are not used by your application.

Goodies for Java EE folks

The executable jar approach for Java web apps is by no means new, but the success of Spring Boot has been noticed by folks in the Java EE “camp”(*). There have been lots of instructions lately on how you can package your Java EE based web apps as executable jar files. For example Tomitribe recently wrote a really nice summary of various ways of how TomEE can be packaged together with your web application to create an “überjar” that you can call “microservice”. Payara Micro is an another approach that just eats your existing war file as a parameter and deploys it to the root context of a trimmed down Payara (a commercially supported GlassFish derivative) instance.

WildFly Swarm is a really interesting start from RedHat. It doesn’t only give you the easy maintenance with executable jar files, but, like Spring Boot, provides you a set of modular building blocks that you can pick into your “custom server”. If you, for example, don’t use JPA in your application, Hibernate won’t be included in your jar file. With this modularity, I see it as a first real “competitor” for Spring Boot.

How it works with Vaadin?

Although Swarm is still more like a research project in alpha state, I wanted to try how it works with Vaadin. And it does, perfectly. Core Vaadin requires just a Servlet container, so you can get started just with the wildfly-swarm-undertow module, typical Vaadin dependencies and a VaadinServlet. But most users probably also want to use the CDI that comes with the wildfly-swarm-weld module and Vaadin CDI. With this setup the only thing you’ll need is a UI class with @CDIUI(“”) annotation and your first Wildfly Swarm powered Vaadin app is up and running.

The easiest way to get started is just to clone the examples project which contains an example setup for a Vaadin app with a UI that is wired to a simple CDI based service. It also requires the latest 1.0.0.Alpha4 release or a development build of Swarm itself, which you can build locally simply with mvn install -DskipTests=true.

Check out the Wildfly Swarm examples with a Vaadin project

(*) I really hate the classification of Java developers into Spring and Java EE tribes, and especially the constant “battles” between them, but there, I just had to do that myself. I love both Spring and Java EE :-)

Use GWT widget as Polymer web component

So you got an existing GWT widget and you would like to publish it to a pure html/JS audience preferably as a Web Component. In this case you have a problem but hopefully this article will help you resolve that problem.

Extra hacks necessary to get it working

  • GWT 2.7.0: enable Js interop compilation by adding the compilation parameter jsInteropMode=JS
  • Make the GWT widgetset compilation result in one file by using the sso linker.

GWT Js interop API

A traditional GWT application is a monolithic chunk of javascript binary that does its magic hidden from plain old JavaScript / html. Luckily as of version 2.7 of GWT the project has released API for next generation GWT/JS interop. See

By annotating classes and types that are supposed to be exposed to javascript the black box of GWT is bleached a bit. Basically you have to annotate everything that is going to be published to javascript in this manner:

public class WebComponentButton extends Button {

Note that these annotations are not transitive so you will not expose any of the methods defined in super classes or interfaces. If you refer another class then that must be exported too. With more complex widgets it is probably easier to write a wrapper class that operates the actual widget than it is to fully export the widget API and it's dependencies.

Please also note the namespace string is starting with $wnd. Without it the exported class is not visible for some reason. It is probably a bug in GWT 2.7. After exporting you can access an object inside the GWT binary in javascript in this manner:

var button = new org.vaadin.webcomponents.WebComponentButton();
button.setText("hello world");

Another detail to consider is that a widget must be added to a root panel or a child of another widget or else it is going to be detached and GWT events will not work. For this an util method that does this is necessary.

public static void add(Widget w, String id) {

Note that the id here has to be unique DOM id which can be generated for example:

public static String getId() {
  return HTMLPanel.createUniqueId();

See a fully working example of utils in found in the example project. 

Special compilation parameter

With version 2.7 this is still very much experimental so in order to enable interop the GWT compiler must be invoked with a special compilation parameter called jsInteropMode that must be set to the value "JS". With maven you would configure it like this in the plugin section:


One file widgetset

It would be more preferable if the GWT compilation result would be just one .js file instead of a multitude of them. This can be accomplished by using the sso linker in widgetset.xml.

<collapse-all-properties />
<add-linker name="sso" />

Access from JavaScript

After exporting the widget it's really easy to start using it with you web component. An example of how to add a GWT button and click listener can be seen below. A working example can be found here.

  ready: function() {
    var button = new org.vaadin.webcomponents.WebComponentButton();
    button.addClickListener(function() {
    this.$ = org.vaadin.util.JSUtils.getId();
    org.vaadin.util.JSUtils.addButton(button, this.$;


After setting the few quirks it's really easy to combine web components and GWT widgets. Granted the interop API is not production ready with GWT 2.7 yet but the upcoming GWT 3.0 looks really promising. Hopefully this example can get you started publishing your existing widgets into the web components world or is a good heads up on what it requires to do so.

For the sake of simplicity this example is focusing on pure GWT not Vaadin but if your Vaadin client side widgets are implemented so that they are GWT widgets and not too dependent on their connectors or server side stuff, this approach is applicable to Vaadin client side widgets too.

See sample project here