This website uses cookies for visitor traffic analysis. By using the website, you agree with storing the cookies on your computer.More information

JVx' VaadinUI and Liferay "self-contained" packages

If you are Liferay User and Vaadin Portlet developer, you know that Liferay has Vaadin bundled. If you develop a Vaadin portlet, you should use the bundled Vaadin version, otherwise it'll be a problem after a deployment.

We solved the problem in JVx' VaadinUI by extending Vaadin. Our implementation allows different Vaadin versions independent of Liferay. Some days ago, Matti Tahvonen posted an article about Using "self-contained" approach to package Vaadin portlets. This is an interesting article because it's exactly what we tried to do :) and we thought that Vaadin developers have a better solution for the problem!

And of course, their solution is better than ours :) But we are like copy cats and we changed our solution because it reduced code and made it easier for us to maintain our codebase. Our idea was not far away from the recommended solution, but we did too much.

To find out what Vaadin did in their archetype, we followed their posted instructions. We found two steps that could be ignored. The first step was the creation of a custom maven profile because it was possible to add all properties to the pom.xml of the project. The second step was the configuration of the profile in Eclipse. Not needed if properties were added to pom.xml.

And after creating the project, we had the recommended solution and it was absoutely trivial. Simply extend VaadinPortlet, extend VaadinPortletService and override getStaticFileLocation. The created source code:

public class CustomVaadinPortlet extends VaadinPortlet {

private static final long serialVersionUID = -13615405654173335L;

private class CustomVaadinPortletService extends VaadinPortletService {


    private static final long serialVersionUID = -6282242585931296999L;

    public CustomVaadinPortletService(final VaadinPortlet portlet,
            final DeploymentConfiguration config) throws ServiceException {
        super(portlet, config);
     * This method is used to determine the uri for Vaadin resources like theme
     * or widgetset. It's overriden to point to this web application context,
     * instead of ROOT context

    public String getStaticFileLocation(final VaadinRequest request) {
        return request.getContextPath();


protected VaadinPortletService createPortletService(
        final DeploymentConfiguration deploymentConfiguration)
        throws ServiceException {
    final CustomVaadinPortletService customVaadinPortletService = new CustomVaadinPortletService(
            this, deploymentConfiguration);
    return customVaadinPortletService;


To be honest... our solution contained a little bit more code but it worked. We've used our new knowledge to improve our solution, because it should be possible to use "self-contained" and "shared" approach without additional source code. We introduced a context parameter to switch between modes. Vaadin could do the same, but currently it's not implemented.

Our new solution is as simple as the original Vaadin source code and the most important thing is that it works with our ant build.

Leave a Reply

Spam protection by WP Captcha-Free