Vaadin

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(() -> {
    // YOUR MAGIC HERE
  }
}

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

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.

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ö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

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.

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 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: johannes@vaadin.com.

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
getDriver().get("https://vaadin.com/home");

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

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:

 $(ButtonElement.class).id("form-save").click();

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.

 $(ButtonElement.class).caption("Save").first().click();

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

 $(PanelElement.class).caption("Form").$(ButtonElement.class)
                .caption("Save").first().click();

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

Servlet 3.0 is awesome, so is CDI. They work well and are a joy to set up. Even adding the Vaadin Navigator to the mix isn’t an issue, since you can use the CDIViewProvider to maintain the injection chains. Everything works nicely with annotations, and you don’t need to mess around with nasty XML. But what if you want to use JAAS? Recently, I stumbled upon a small dilemma in a customer project where the customer wanted to use JAAS in combination with CDI. How in the world was I going to combine the two?

To get us all to the same page before we start; here is a very short introduction to JAAS. JAAS, or the Java Authentication and Authorization Service, has been around for a while. It is an API for Java to manage user authentication and request authorization, with a multitude of connectors to other technologies and pre-made helpers. In this post I’m going to show you how to integrate the authentication part into your Vaadin application, using the Vaadin CDI plugin and JBoss 7.1. The blog post is a summary of my Wiki article. It contains complete source code and a more thorough explanation on the different parts.

So, how do we really make this work?

There are a couple of ways we can configure the Servlet to have both JAAS and CDI capability; both involve the actual mappings of the Servlet. If you map your Servlet in your web.xml, you can use CDI by using the CDIUIProvider utility class. It scans the classpath for @CDIUI annotations and deploys the classes automatically. If you’re not using web.xml, you can define the same thing in your servlet by injecting the provider and adding it to the session. In my example, I just use the pre-made servlet definition included in the CDI addon. It is preconfigured to use the CDIUIProvider, so I just create the necessary UIs and annotate them, and I’m good to go, like this:

 @CDIUI("secure")
public class SecureUI extends UI

That’s how you get CDI to work, what about JAAS? Well, we can restrict the user in two ways; web.xml-based security constraints, or restricting the access to mapped Navigator Views using the @RolesAllowed annotation. Since we aren’t using the Navigator, we need to use the web.xml file approach. If you already have the file, then you just add the security constraints. If not, you need to create a web.xml file under your WEB-INF folder. You don’t need to add any servlet definitions; you only need to work with URL mappings. With JAAS, you define which URLs are off-limits to normal users. If you have a Servlet deployed there or not is actually moot; JAAS only controls access to that URL, it doesn’t care what’s there. You also define where the login-page exists with another URL.

In my example I, have a secure area of my application mapped to /secure, an unsecure area mapped to the root (/), and a login page on /login. I tell JAAS that /secure is a secure zone: users must log in to access it. If a user isn’t logged in, they get redirected to a login page. In our case it is /login. The user logs in, and the server grants access to /secure. Fragment below:

 <login-config>
    <auth-method>FORM</auth-method>
    <realm-name>ApplicationRealm</realm-name>
    <form-login-config>
        <form-login-page>/login</form-login-page>
        <form-error-page>/login</form-error-page>
    </form-login-config>
</login-config>

How you actually log in the user is completely up to you. In my example I use a Vaadin UI with a relational database to store user info, and have JBoss fetch the user data with SQL. You could also set up Active Directory, LDAP, a simple file-based system. You could use existing JSP (or even plain HTML) for the actual login UI. There are lots of tutorials for the different solutions, so I won’t cover them here. Check the wiki article for detailed information about the database method, including all source code and JBoss configs.

Now that you have JAAS enabled, what benefits do you get? Well, a lot actually. With JAAS, you get access to a properly defined authentication and authorization framework, that is built into all application servers. You can easily separate your security concerns into a separate, maintainable module. With CDI and EJBs, you can use standard-based security protocols for bean access. If you are using the Vaadin Navigator, you can even define access control restrictions on your Views with the @RolesAllowed annotation found in JAAS. Most importantly, using JAAS lets you concentrate on your application instead of the security for it.

That’s it, your app will now use JAAS authentication and CDI. The configuration provided in the wiki article isn’t complete, and there are small pieces I didn’t really cover, but it will work for basic cases. From here, you can add authorization for your particular application. Anything I missed? Anyone used JAAS with CDI, and want to share your thoughts? Feel free to add comments below.

The full Wiki article

Thomas Mattsson works at Vaadin as a Vaadin Expert and Project Manager. He has been designing and implementing Vaadin application architectures for over 5 years. When he isn’t designing, he runs around Europe doing Vaadin trainings and consulting gigs. You might also catch him on the Vaadin Forum.