Vaadin Community Spotlight - April 2014

Spotlight, featured image

Vaadin community is huge and growing. There is lots of stuff happening “behind the scenes” that don’t get enough attention among our average users. Thus we have decided to start this new style of article series that will bring up some cool efforts. To keep the story short enough, we’ll never be able to cover everything, but I’m still interested in all the tips for the upcoming episodes.

Those of you who are enthusiastic about Java 8 and strictly structured UI code should definitely check out Nicolas Frankel’s entry in Learning Vaadin blog. He presents how lambda expressions can be used to simplify code using separate event listener objects and Guava event bus.

Continuing on well structured code, you should check out Peter Lehto’s work in progress app stubb. It has a multimodule Maven build, Apache Shiro authentication and MVP structured UI code examples, so it should suit as a nice starting point for even larger apps. If your French is more fluent than mine, you can also continue on the CDI-MVP topic in IP-TECH blog.

I have been helping Peter a bit in his example app. The very first thing I did was to make it look great. The trick was to use the yet to be released Valo theme. I have made a “fork” of the upcoming Valo project that uses sass-maven-plugin to compile the theme. You can check out the project, optionally parametrize it and build with just mvn install - nothing else needed. Then just add the dependency (or drop in the jar to WEB-INF/lib) and annotate your UI with @Theme("dawn"). It works pretty well even with the 7.1 series. The CDI app stub actually gives a much nicer overview of Valo theme than my rudimentary example app.

The add-on count in Directory also keeps growing. My favorite from the latest arrivals is Jarno Rantala’s simple, but yet powerful add-on, Lazy List. It might fill your common requirement in mobile web apps, but it is priceless even for plain “desktop apps”. It allows developers to hook to event when the user scrolls to the end of the view. Most commonly you’d then load stuff to your “eternally scrollable list”. Lots of web apps like Twitter use this approach nowadays. It is now super simple to implement with Vaadin as well.

We’ll be posting these Community Spotlights also in the future. In case you suspect we have missed your efforts, let us know about your activities via Tori or Twitter with the hashtag #Vaadin.

Vaadin in Akka

Concurrency and distributed systems are probably among the hardest parts of software engineering. Basic Java EE apps usually don’t need to deal with these issues that much, but increasing parallel computing resources in servers and constantly open client-server connections, like WebSockets, bring these problems closer to web app developers as well.

Although average web developers don’t that often need to fight with these hard “academic” problems, there are some areas of engineering where the problems of concurrency, distributed systems and their reliability play possibly the most important role. In e.g. telecom, nodes must be working tightly together, but one failing node can’t take the whole system down. New nodes and roles must be pluggable to a live system and it must even be able to heal itself from malfunctions automatically.

Built-in concurrency helpers in Java have been improving in almost every major release, but building non-trivial concurrent systems right is still a difficult task. Akka is a framework that tries to make solving these problems easier. Its so-called “actor model” adds some limitations and clear borders for execution units.

An actor can be seen as protected zone, in which its execution is always “thread safe”. For external communication, independently of the actors actual implementation, there is only one standard API: tell(message, sender). So, you can send a (serializable) message to it and that’s it. Implementing actors is then by no surprise just handling these messages. The actor system works as “a message bus” and orchestrator for well decoupled actors.

Although some might say the actor model limits their possibilities as a developer, it is a proven way to safely solve these overly complex problems. In the same way that Vaadin helps in web development, Akka helps in concurrency and distributed systems: it sets developers free to solve the actual domain problems.

Creating Vaadin UI to an Akka actor system

Akka is a JVM based system, with both Java and Scala APIs, so the task is in theory super easy. But, there is the concurrency part that you don’t want to fail. There are two places where a developer could possibly fail with the concurrency: sending messages to the Akka system and receiving messages from there.

From Vaadin to Akka is actually pretty bullet proof, no matter how you do it. Due to Akka’s model, you just can’t do it wrong here and Vaadin adds no extra complexity here. Sending a string “hello” to an actor might look like this:


 actor.tell("hello", ActorRef.noSender());


The bit trickier part is getting the information back from the actor system into Vaadin UI. If the actor is expected to answer soon to your message, the simplest method is to use “ask pattern”. The helper will return a Future containing the possible answer:


 button.addClickListener(event -> {
  Future<Object> f = Patterns.ask(actorRef, "message", 1000); // 1000 ms timeout
  Object answer = f.value();


You could also achieve similar results using a helper called Inbox. These solutions are also bullet proof in terms of concurrency. The whole execution of telling, waiting for an answer and updating the UI is from a user initiated thread. But in case getting the response from the system takes long, we’d definitely not want to block the UI waiting for the response. We’d need some sort of asynchronous communication with the Akka actor system.

In the example app I recently built, there is a slightly more sophisticated example suitable for receiving data from the system outside user interaction cycle. In the Reactive Stock example, the actor system produces random stock prices that we want to report to our layer UI eagerly. For each Vaadin UI instance, we create a special actor that registers itself to listen to selected stock symbols and that passes updates to its UI instance.

This kind of integration is finally something that can go wrong. As changes are now originated from a thread that is not initiated by user interaction, Vaadin can by no means do proper synchronization for the changes. Thus, all changes to the referenced UI must now be done with an explicitly locked session. The UI class has a handy helper method to which you can pass your changes as a standard Runnable instance. Vaadin then takes care of doing synchronization. In the example I did, this Vaadin specific “trick” is in a public UI method that is called by the UIActor. Here a clean Java 8 style Runnable is created with lambda expression:


 public void updateStockDetails(String stockSymbol, StockQuote... values) {
  access(() -> {


The full example is available via TypeSafe Activator and also via GitHub as a Maven build project so you should get started with it easily in your favourite IDE. Play with it for a while and you are ready to impress your company’s concurrency gurus with a clean cool RIA UI built with plain Java!

Matti TahvonenMatti Tahvonen is a Vaadin "R&D veteran" who has been working with our products for over 6 years. His current responsibility is to keep you up to date with latest and greatest Vaadin related technologies. You can follow him on Twitter – @MattiTahvonen

Tori, the Liferay forum on steroids

We're pleased to announce the public release of Tori – the modern and sleek discussion forum for Liferay portal. We've kept Tori under the blanket while developing it and gathering feedback from you in the Vaadin community for more than a year, but now the time has finally come to turn on the spotlights and direct them at Tori.

Did you think you knew Tori? Look again. It's completely renewed since 4 months ago, with a new look and feel and many smaller enhancements since then.

What then makes Tori special? Isn't there a Message Board inside Liferay already by default?

Tori is a full-blown single page application where you move smoothly between threads and topics. Another central part of Tori is push messages. Whenever somebody posts a message or is writing something in the same thread as you (psst! did you notice the rich text in-place editing of your posts?), you'll immediately see what's going on in real-time.

The largest enhancement in the latest release, Tori 1.1, however, is continuing the beautiful UI experience to your mailbox. And being a generic portlet, all this is tweakable in the admin console of Tori, so that you can make it look just like your own portal. And even more enhancements based on your feedback are in queue.

Tori Liferay Forum HTML emails

Tori 1.1 by default sends HTML emails that look like your forum continuing the user experience outside your forum

The theme in Tori is customizable with Sass (or CSS) to fit your look and feel. You'll be able to make it look like your own site, online as well as in the emails. But we didn’t stop there. You can also create your own custom tags. We've even started hosting our Webinars inside Tori through a custom youtube-tag.

We've also built in SEO support so that search engines crawling the site can crawl for all the relevant data while at the same time maintaining full backwards compatibility with Liferay's own message board. And you can add Google Analytics by just adding your UA-code to the settings screen. Tori is a full drop-in-replacement for Liferay Message Board that follows your message board settings and privileges plus so much more.

Tori, meaning 'town square' in Finnish, is available through Liferay Marketplace as a free download. You can also get it as source code directly from GitHub.

Tori will work inside any Liferay instance starting from version 6.0 and you can even run it simultaneously with the native Liferay Message Board. There’s no reason why you shouldn’t use it today.

Get Tori from Liferay Marketplace

Fredrik RönnlundFredrik Rönnlund has been working at Vaadin Ltd since 2008. Today he works as the Batman of Vaadin Marketing, helping create meaningful content to the Vaadin users by day and fighting evil bugs by night. You can follow him on Twitter – @freducom

Scalability testing with JMeter

There is a point in every enterprise web application project when the scalability of the application under development is wanted to be measured. There are several reasons for why scalability tests are done. To begin with, there is a need to see how the application will perform on production like environment. Then, the peak performance or breaking point of the application is wanted to be found out. Finally, scalability tests can be utilized to find performance bottlenecks, bugs and memory leaks.

We in Vaadin take scalability seriously. That is why we built a full stack application called QuickTickets a couple of years ago. QuickTickets has been our platform for scalability studies. If scalability is of any kind of interest to you, you should check out the Vaadin Scalability Study blog post which is still valid today. 

Apache JMeter has most often been the de facto tool for scalability studies. Apache JMeter is an open source desktop application designed for Web Application performance testing. JMeter does not render the UI in a browser like Vaadin TestBech and Selenium do, but instead it has the ability to simulate and gauge a server load of hundreds and thousands of concurrent web users. This functionality is achieved by recording the client to server requests of the Web Application which is then played back by several numbers of concurrent threads.

jmeter screenshot

QuickTickets is based on Vaadin 6; so are there any changes in Vaadin 7 that the scalability tester should be aware of? Yes, there is, at least one. In Vaadin 6 you could set component ids used in the client-server communication using the setDebugId() method. By default, a Vaadin application sets a sequential id for each component of the application. This id sequence is likely the same between different runs of the application, but this is not guaranteed. By setting the component id by hand, it helps you to keep your test valid even when your Vaadin UI is changing during the application development.

In Vaadin 7 the setDebugId functionality has been removed, since it might cause problems if the ids set by the user are not unique. In order to make your scalability testing as smooth as possible, I've prepared a tutorial that oulines the measures you need to take to test your Vaadin application. Please, take a look at the step-by-step tutorial of testing Vaadin 7 applications with JMeter. It covers JMeter testing of both Vaadin 6 and Vaadin 7 applications. And as always, if you have any comments or questions, post them here and I'll get back to you.

Read more in the wiki

Johannes Tuikkala Johannes Tuikkala works as a Vaadin Expert who has been working in different customer projects for 6 years. He likes to do photography and winter swimming on his free time. You can reach him by email:

Webdriver and object oriented testing in TestBench 4

Vaadin TestBench is a browser automation tool, suited for creating UI level tests for Vaadin applications. It is based on Selenium 2, which means that all features of Selenium 2/WebDriver are also available in TestBench. But what exactly does Selenium 2 / WebDriver do? And how does Vaadin TestBench work?

Like many of you might know, Selenium has been around for quite some time. Started in 2004, the first version was solely JavaScript based. It was a small JavaScript application running in the browser, commanding the application to be tested.

WebDriver takes a different approach to solve the same problem. Rather than being a JavaScript application running within the browser, it uses whichever mechanism is most appropriate to control the browser and to bypass the restrictions placed on the browser by the JavaScript security model. This allows Vaadin TestBench to use a cleaner, object-based API, rather than follow the original dictionary-based API. This is also what Vaadin TestBench uses:

 // Create an instance of Firefox
setDriver(new FirefoxDriver());

// Now go to the Vaadin home page

// Find the search input and run a search
WebElement siteSearch = driver.findElement("query"));
siteSearch.sendKeys("vaadin charts");

In TestBench 4 Selenium’s object-oriented API has been taken even further. The Vaadin element query API helps Vaadin developers find Vaadin components and access their properties in the browser. These component properties include caption, description, child components, cells in tables – as well as Vaadin specific actions like closing notifications. The Element APIs in the com.vaadin.testbench.element package extend the org.openqa.selenium.WebElement which makes them fully compatible with Selenium.

With Vaadin TestBench the components are queried like this:

 List<ButtonElement> buttons = $(ButtonElement.class).all();

Here the ButtonElement class is a specialized WebElement, which contains API for interacting with Vaadin Button components. There are Element class counterparts for all the core Vaadin components in Vaadin TestBench and add-ons can introduce their own when needed.

You can use several different ways to locate and interact with the UI component elements.

The most robust way is to use component identifiers. To use these, you first need to set unique identifiers for your components in the application code. A save button in a form could, e.g. use btnSave.setId(“form-save”). In the test code you can then click the actual element by calling:


When IDs are not available, you can use the caption to find a Vaadin component in your application. Often enough the caption is a unique enough identifier for your component, as you rarely have too many components of the same type with the same caption.


ElementQueries also allow you to define a search hierarchy, which means that you can easily search components within components.


Of course you can do most of the same things with XPath using Selenium’s rather complex but powerful syntax. Vaadin TestBench 4 is fully compatible with your existing test cases and will stay that way.

This was a glimpse into the upcoming Vaadin TestBench 4. Check out the examples in GitHub, but if you want to use Vaadin Testbench now, Vaadin TestBench 3 is fully forward compatible (also license-wise) and a safe way to start automating your browser testing today.

Jonatan KronqvistJonatan Kronqvist is a Senior Vaadin Expert leading a team of awesome developers building the next versions of Vaadin, TestBench and other tools that streamline the development process and help our customers build the best UIs in the world.

Showing 1 - 5 of 259 results.
Items per Page 5
of 52
We’re releasing a preview version of an add-on, simply called Vaadin Responsive, for making responsive design possible in Vaadin applications. With this early version, we hope to gather feedback
The community has always been important to us, and continues to be so. We do our best to provide interesting technologies, articles and other insights for you. Apparently we’ve done some
Let’s start with the bad news: We have chosen to postpone Vaadin 7.1 beta 1 to the beginning of May with a stable release coming a month later. The main reason for this delay is that we want to
  Three years of Vaadin Directory Vaadin Directory has turned 3 years of age already. The Vaadin Framework itself features a lot of widgets and components, but it cannot have all
I recently had the opportunity to work on WAI-ARIA additions to the Vaadin core framework. WAI-ARIA is short for Web Accessibility Initiative - Accessible Rich Internet Applications Suite.
Showing 91 - 95 of 100 results.
of 20

See all blog entries
Subscribe to this blog