Developing a Portlet in Vaadin 7


So I wanted to provide an example Vaadin portlet built using the Vaadin 7 shared environment.  Currently I've been migrating my general development efforts over to Intellij, so I thought this would be a good time to try out creating a Vaadin 7 portlet in Intellij and Maven.  The results are outlined in the rest of this blog entry.

Creating the Project

So to create the project, I just used Intellij's Maven integration to create a Liferay portlet.  From the starting page, I chose "Create New Project".

Intellij Starting Page

For lack of anything better, I used the Maven type to create a new Liferay portlet.  I used the liferay-portlet-archetype which, by default, creates a new Liferay MVC portlet, but we'll take care to remove that later on.  It will provide all of the right plumbing though to get the project started.

Create Maven Project

For the new project you have to specify your Maven artifact details.  The values I used are below.  One important note, there are some versions of Liferay and/or some application servers which require a plugin to include the plugin type as a suffix in the name.  I tend to just do that now for all Liferay artifacts just so I automatically include "-portlet" in the artifact id.

Maven Archetype Details

Next page you can review and, if necessary, change the settings being passed to Maven:

Maven Settings

Finally specify the project name which I've kept the same as my Maven artifactId.

Project Name

Updating the Project Files

Before we start creating the Vaadin source files we have to modify some of the project files.

The first easy modification to the project is to delete the view.jsp file, the icon.png file, the js directory and the css directory, all generated for the portlet by the archetype.  These files/directories will not be needed so there's no reason to keep them any longer.

Update pom.xml

The basic pom.xml file created by the archetype is set up for a Liferay MVC portlet.  We need to add some parts to it to leverage the Vaadin shared environment.

Before the <dependencies /> section, we have to define a new <repository />.  Insert the following:

<repositories>  <repository>  <id>vaadin-addons</id>  <url></url>  </repository> </repositories> 

This adds the Vaadin Add On repository definition to the project so Maven will be able to find dependency jars.

We also need to add a number of dependencies to the project:

<dependency>  <groupId>com.vaadin</groupId>  <artifactId>vaadin-server</artifactId>  <version>7.2.7</version>  <scope>provided</scope> </dependency> <dependency>  <groupId>org.jsoup</groupId>  <artifactId>jsoup</artifactId>  <version>1.6.3</version>  <scope>provided</scope> </dependency> <dependency>  <groupId>com.vaadin</groupId>  <artifactId>vaadin-sass-compiler</artifactId>  <version>0.9.6</version>  <scope>provided</scope> </dependency> <dependency>  <groupId>com.vaadin.external.flute</groupId>  <artifactId>flute</artifactId>  <version>1.3.0.gg2</version>  <scope>provided</scope> </dependency> <dependency>  <groupId>net.sourceforge.cssparser</groupId>  <artifactId>cssparser</artifactId>  <version>0.9.11</version>  <scope>provided</scope> </dependency> <dependency>  <groupId>org.w3c.css</groupId>  <artifactId>sac</artifactId>  <version>1.3</version>  <scope>provided</scope> </dependency> <dependency>  <groupId>com.vaadin</groupId>  <artifactId>vaadin-shared</artifactId>  <version>7.2.7</version>  <scope>provided</scope> </dependency> <dependency>  <groupId></groupId>  <artifactId>android-json</artifactId>  <version>0.0.20131108.vaadin1</version>  <scope>provided</scope> </dependency> <dependency>  <groupId></groupId>  <artifactId>guava</artifactId>  <version>16.0.1.vaadin1</version>  <scope>provided</scope> </dependency> <dependency>  <groupId>com.vaadin.external.streamhtmlparser</groupId>  <artifactId>streamhtmlparser-jsilver</artifactId>  <version>0.0.10.vaadin1</version>  <scope>provided</scope> </dependency> <dependency>  <groupId>commons-lang</groupId>  <artifactId>commons-lang</artifactId>  <version>2.6</version>  <scope>provided</scope> </dependency> <dependency>  <groupId>org.vaadin.addons</groupId>  <artifactId>lazy-paged-container</artifactId>  <version>1.0.0</version>  <scope>provided</scope> </dependency> 

This pulls in all of the Vaadin jars and dependencies.  Additionally I've included commons-lang and the lazy-paged-container Add On jar that the portlet will be using.

Note that the <scope /> being used for all of the jars is "provided".  Maven will include the jars to satisfy compiling the Java code but will exclude them from the built war file artifact.

Updating the Portlet.xml File

The archetype generated an initial portlet.xml file that contains the values for the Liferay MVC portlet.  We'll strip that portlet definition out and replace it with the one we need for Vaadin:

<portlet>  <!-- Keep portlet names simple -->  <portlet-name>vaadin-users</portlet-name>  <display-name>vaadin-users</display-name> 
 <!-- Normal Vaadin portlets will use this class as the portlet class -->  <portlet-class>com.vaadin.server.VaadinPortlet</portlet-class> 
 <!-- Specify the main UI class which will be instantiated by the portlet -->  <init-param>  <name>UI</name>  <value>com.dnebinger.liferay.vaadin.sample.UsersUI</value>  </init-param>  <!-- Specify the use of the shared portal widgetset -->  <init-param>  <name>widgetset</name>  <value>com.vaadin.portal.gwt.PortalDefaultWidgetSet</value>  </init-param> 
 <expiration-cache>0</expiration-cache>  <supports>  <mime-type>text/html</mime-type>  </supports>  <portlet-info>  <title>Vaadin Sample</title>  <short-title>Vaadin Sample</short-title>  <keywords>vaadin sample portlet liferay users lazy container</keywords>  </portlet-info>  <security-role-ref>  <role-name>administrator</role-name>  </security-role-ref>  <security-role-ref>  <role-name>guest</role-name>  </security-role-ref>  <security-role-ref>  <role-name>power-user</role-name>  </security-role-ref>  <security-role-ref>  <role-name>user</role-name>  </security-role-ref> </portlet> 

The important parts here are the <portlet-class /> value and the UI init param.

The given portlet class is the class to use for Vaadin 7-based portlets.  Unlike GenericPortlet where you often need to subclass the portlet to provide an implementation with your business logic, the VaadinPortlet class rarely (if ever) needs to be subclassed.

The UI <init-param /> value is the class for the main UI class for your portlet.  This class extends com.vaadin.ui.UI and handles the initialization of the Vaadin portlet views.  The UsersUI class referenced here will be discussed later.

The remainder of the <portlet /> contents are standard entries used by many other portlets.  Customize as necessary.

Although not highlighted here in this blog, you should update the liferay-display.xml file using the value from the <portlet-name /> tag.

Updating the Liferay-Portlet.xml File

The next file to update is the liferay-portlet.xml file.  Again the Liferay MVC portlet entry will be stripped, and the Vaadin portlet entry must be added:

<portlet>  <!-- Must match the value of the <portlet-name /> tag from portlet.xml. -->  <portlet-name>vaadin-users</portlet-name>  <!-- Instanceable indicates whether multiple copies are allowed on the same page. -->  <instanceable>false</instanceable>  <!-- ajaxable should always be false for Vaadin portlets -->  <ajaxable>false</ajaxable> </portlet> 

Not really much here.  Javascript and CSS files are not normally used (you don't need separate JS files for Vaadin and styling comes from the Vaadin theme).  Many of the other standard values used in other portlet frameworks are not necessary for Vaadin portlets.

The only tag that is necessary is the <ajaxable /> tag, this value should be set to false for all Vaadin portlets.

Updating the Liferay-Plugin-Package.Properties File

The next file to modify is the file.  The change we're going to make here is the inclusion of the portal dependency jars that will be included during hot deployment.

Our file looks like:

name=vaadin-sample-portlet module-group-id=liferay module-incremental-version=1 tags= short-description= change-log= page-url= author=Vaadin On Liferay licenses=LGPL 
# First the vaadin jars, then the addon jar(s), then spring jars. portal-dependency-jars=\  vaadin-server.jar,vaadin-shared.jar,guava-vaadin.jar,atmosphere-runtime-vaadin.jar,jsoup.jar,streamhtmlparser-jsilver-vaadin.jar,\ vaadin-slf4j-jdk14.jar,json-java.jar,\  LazyPagedContainer.jar,\  commons-beanutils.jar,commons-collections.jar,commons-lang.jar,commons-io.jar,commons-pool.jar,commons-configuration.jar,commons-digester.jar,\  spring-core.jar,spring-asm.jar,spring-context.jar,spring-context-support.jar,spring-expression.jar,spring-transaction.jar,spring-web.jar,spring-aop.jar 

Remember all of those provided scopes in the pom.xml file?  By declaring them as provided, Maven would not include the jars in the /WEB-INF/lib directory.  But since we need them after deployment, we list them as portal-dependency-jars so they all get pulled in.

By listing the Vaadin jars, the version of Vaadin 7 the portal is using will get pulled into your portlet during hot deployment.  This will ensure that your portlet has the same Vaadin version as the portal, and when Vaadin is upgraded (using the Vaadin 7 Control Panel), the version of Vaadin used by this portlet will be upgraded also.

The LazyPagedContainer.jar file is also listed as a dependency.  In my last blog entry, I demonstrated how to deploy the LazyPagedContainer Add On using the Vaadin 7 Control Panel.  If I had any other Add Ons that I wanted to use in this portlet, I would first deploy them using the Vaadin 7 Control Panel and recompile the widgetset.  Then I can include the jar file(s) as portal-dependency-jar entries and I can use the Add On(s) in my portlet.

Writing the Vaadin Portlet Code

Now this is where I need to back peddle a little bit...

Remember when I said I was going to do this portlet in Intellij?  Well that really was my plan.  But I got to this point where I was ready to start my CustomComponent subclasses and I just stopped.  Basically I was just unwilling to hand-code the initial component classes, defining all of the layouts and widgets, figuring out their alignment, etc.

So I quickly caved and fired up my trusty version of Eclipse that has the Vaadin IDE plugin installed.  If you are going to be doing Vaadin development, either for servlets or portlets or both, you really, really need this Eclipse plugin.

I mean, sure, I could decide to use a primary layout as a VerticalLayout, the first entry being a HorizontalLayout that has a VerticalLayout on the left (with the user detail labels) and an Embedded for the user portrait on the right, and the main VerticalLayout has a Button that is right aligned for the Back link.  I could declare all of the private members, write all the code to construct and initialize the components and wire them into the appropriate heirarchy.

But who would when you can lay everything out graphically?

Vaadin IDE

Isn't that sexy?  You can't do anything like this with your JSP frameworks, your javascript frameworks, your jsf frameworks, ...  And this isn't some storyboard or anything like that, behind the scenes the Vaadin IDE is reworking the Java code that implements what you see in this view.  In the end, the generated code is by no means complete (no event handlers are wired, etc.), but this is such a great head start towards building your views it is just too hard for me to give up.

So basically I started my Eclipse environment and created a fake Vaadin servlet so I could start my CustomComponents that I would be using in my portlet.  I laid them out visually such as you see above.  When I was done with the visual layout, I switched over to the code view to find all of the Java code the Vaadin IDE generated for me, copied it all, then switched over to Intellij to create the java classes and pasted all of the Vaadin IDE-generated code into my new class in Intellij.

Unfortunately there is no current Vaadin IDE plugin being built for Intellij (that I know of), so at some point I'm going to be faced with the choice to continue this awkward process (since I don't want to give up the Vaadin IDE) or bail on Intellij and stick with Eclipse to keep the Vaadin IDE close.  I'm new to Intellij and haven't developed the commitment to it that others have, so I'm not sure which way I'll end up going, but I'll keep you up to date.

Now back to the code...

Portlet Component Decomposition

For my interface, I decomposed it into the following components:

  • A detail component - The basic interface shown above, simply a page which shows basic user details and the user portrait.  Works on a single user.
  • A list component - Shows the list of Liferay users.  Will leverage the LazyPagedContainer to manage the pull of data from the Liferay API.
  • A tab component - Tab components (with tabs hidden) happen to be an easy way to quickly switch back and forth between the (hidden) tabs.  On one tab I'll put the list component and the other tab will have the detail component.  When a user is selected from the list, I'll switch tabs and update the detail component.  That back button on the detail page?  That will just get the tab component to switch back to the list component.
  • The UI class - This is needed by every Vaadin portlet to control the creation of the UI elements.

So, let's review some of the code.

The UserDetailComponent

The UserDetailComponent is the java class that implements the interface shown above.  Below is the class constructor:

public UserDetailComponent(UsersUI uui) {  // Invoke the Vaadin IDE code to build the widget heirarchy from the visual design.  buildMainLayout();  setCompositionRoot(mainLayout); 
 // set the initial values  screenName.setValue("");  emailAddress.setValue("");  userId.setValue("");  name.setValue(""); 
 // also need to clear the portrait, initialize it to the basic male portrait.  String maleUrl = UserConstants.getPortraitURL(uui.getThemeDisplay().getPathImage(), true, 0); 
 // set the url as the source for the user portrait.  userPortrait.setSource(new ExternalResource(maleUrl)); 
 // change the back button style to a link.  backLink.setStyleName(Runo.BUTTON_LINK); 
 // add the back link listener.  backLink.addClickListener(new Button.ClickListener() {  @Override  public void buttonClick(Button.ClickEvent clickEvent) {  // get the ui object  UsersUI uui = (UsersUI) getUI(); 
 // invoke our little switch method.  uui.switchToListView();  }  }); } 

The Vaadin IDE-generated code is invoked to initialize the view per the visual design.  The Labels are updated to clear out the initial values.  

The userPortrait is an Embedded component that will be used to show the user portrait; if the user doesn't have a portrait, the basic male portrait will be used, and that's what we initialize the value to.  Using this type of component, we will be able to show the real user portrait the user might have loaded to their profile.

The style of the Back button is changed to a link, basically it will look like a hyperlink.  A click listener is also added to deal with clicks on the link.  Inside the click listener, we get the UI instance the component is bound to (our UsersUI instance) and the switchToListView()  method is invoked to handle the switch.

In Vaadin, the UI instance is accessable to every component that is added to the heirarchy.  This makes the class a great extension point to add utility methods or manage navigation.

When switching to the detail view, the component needs to update with information for the user.  Here's the method:

/**  * updateFromUser: Updates the screen elements for the given user id.  * @param uId User id to update the view for.  */ public void updateFromUser(final long uId) {  User user = null; 
 try {  // try to get the user given the uId...  user = UserLocalServiceUtil.fetchUser(uId);  } catch (SystemException e) {  logger.error("Error fetching user " + uId + ": " + e.getMessage(), e);  } 
 UsersUI uui = (UsersUI) getUI(); 
 if (user == null) {  // we could not get a user record. Reset all fields and return.  screenName.setValue("");  emailAddress.setValue("");  userId.setValue("");  name.setValue(""); 
 // also need to clear the portrait  String maleUrl = UserConstants.getPortraitURL(uui.getThemeDisplay().getPathImage(), true, 0); 
 userPortrait.setSource(new ExternalResource(maleUrl)); 
 return;  } 
 // set the labels from the values for the user.  screenName.setValue(user.getScreenName());  emailAddress.setValue(user.getEmailAddress());  userId.setValue(String.valueOf(uId));  name.setValue(user.getFullName()); 
 // also need to update the portrait.  String portUrl = null; 
 try {  // get the portrait url for this user  portUrl = user.getPortraitURL(uui.getThemeDisplay());  } catch (PortalException e) {  logger.error("Error getting user portrait url: " + e.getMessage(), e);  } catch (SystemException e) {  logger.error("Error getting user portrait url: " + e.getMessage(), e);  } 
 if (StringUtils.isBlank(portUrl)) {  // don't have a url, default to the male portrait  portUrl = UserConstants.getPortraitURL(uui.getThemeDisplay().getPathImage(), true, 0);  } 
 // update the portrait  userPortrait.setSource(new ExternalResource(portUrl)); } 

The comments here are self explanatory.

The line for getting the portrait URL for the user shows a call to a utility method exposed in the UsersUI class, the getThemeDisplay() method.  This method does what it says, it returns the current ThemeDisplay instance that is needed to get the portrait URL.  This method will come up later.

The UserListComponent

The UserListComponent is used to display the list of Liferay users.  It too was laid out using the Vaadin IDE in Eclipse, and that code was used in Intellij as the foundation for the class.  I just had to add the code to initialize the table:

public UserListComponent() {  buildMainLayout();  setCompositionRoot(mainLayout); 
 // This container, based on the LazyPagedContainer, encapsulates the access to the UserLocalServiceUtil  // class and it's methods to get to the users.  userContainer = new LazyUserContainer(); 
 // do not allow row selection  users.setSelectable(false); 
 // set the container as the data source for the users table.  users.setContainerDataSource(userContainer); 
 // we want name, email, and screen name to be a link to click to the detail page, so we will add them  // as extra columns that are buttons.  users.addContainerProperty(FIELD_FULLNAME, Button.class, null, NAME, null, null);  users.addContainerProperty(FIELD_EMAILADDRESS, Button.class, null, EMAILADDRESS, null, null);  users.addContainerProperty(FIELD_SCREENNAME, Button.class, null, SCREENNAME, null, null); 
 // Since those columns will be buttons, they need to be generated. This generator will be used  // to generate the column objects (since they are not a natural member of the User class).  userColumnGenerator = new UserColumnGenerator(); 
 // Add the generated columns.  users.addGeneratedColumn(FIELD_FULLNAME, userColumnGenerator);  users.addGeneratedColumn(FIELD_EMAILADDRESS, userColumnGenerator);  users.addGeneratedColumn(FIELD_SCREENNAME, userColumnGenerator); 
 // add our visible columns so only the generated are used.  // this will leave the other members of the User class outside of it.  users.setVisibleColumns(new Object[] {FIELD_FULLNAME, FIELD_EMAILADDRESS, FIELD_SCREENNAME}); 
 // refresh the rows  users.refreshRowCache(); } 

The LiferayUsersComponent

The LiferayUsersComponent manages the tab widget with our two views as tab pages (the tabs themselves are hidden).  This component was also laid out using the Vaadin IDE in Eclipse, and the generated code was copied to Intellij to edit.  I didn't really change any code in this class, however, I just added two utility methods for switching to selected tabs:

/**  * switchToListView: Switches to the list view tab.  */ public void switchToListView() {  // choose the list tab.  userPages.setSelectedTab(userListTab); } 
/**  * switchToDetailView: Switches to the detail view tab.  * @param userId The user id to display details for.  */ public void switchToDetailView(final long userId) {  // choose the details tab...  userPages.setSelectedTab(userDetailTab); 
 // update the detail view for the selected user.  userDetailTab.updateFromUser(userId); } 

The UsersUI Class

The UsersUI class is not generated by the Vaadin IDE, you have to create this yourself.  Since the UsersUI class is pretty small, it will be presented in whole:

package com.dnebinger.liferay.vaadin.sample; 
import com.liferay.portal.kernel.util.WebKeys; import com.liferay.portal.theme.ThemeDisplay; import com.vaadin.annotations.Theme; import com.vaadin.server.VaadinPortlet; import com.vaadin.server.VaadinPortletService; import com.vaadin.server.VaadinPortletSession; import com.vaadin.server.VaadinRequest; import com.vaadin.ui.TabSheet; import com.vaadin.ui.UI; import com.vaadin.ui.VerticalLayout; 
import javax.portlet.PortletRequest; 
/**  * class UsersUI: Simple UI class to demonstrate Vaadin in the portal. Highly commented for Liferay developers.  *  * The UI extension class is the main entry point for your Vaadin portlet. It is here that you will create your initial UI.  *  * @version 1.0  * @author dnebinger  */ 
// Use the standard Liferay theme for the widgets. @Theme("liferay") public class UsersUI extends UI { 
 private VerticalLayout mainLayout; 
 private LiferayUsersComponent usersComponent; 
 /**  * init: The extension point, define the initial UI for the interface.  * @param vaadinRequest The initial request which is used to initialize the display.  */  @Override  protected void init(final VaadinRequest vaadinRequest) {  // create the main vertical layout  mainLayout = new VerticalLayout(); 
 // give it a margin and space the internal components.  mainLayout.setMargin(true);  mainLayout.setSpacing(true);  mainLayout.setWidth("100%");  mainLayout.setHeight("100%"); 
 // set the layout as the content area.  setContent(mainLayout); 
 // In the portal, the main widget cannot have an indeterminate height or it just won't render. There's a number  // of things going on between the Liferay JS, the Liferay CSS, and the GWT and Vaadin. There is a bug open on  // Vaadin, but until it is resolved it's best to come up with a reasonable height and set it. Note this is just  // an initial height to get it to render, there are corresponding things that can be done to update the height  // later on...  setHeight("600px");  setWidth("100%"); 
 // create the users component, the component that has the (hidden) tabs.  usersComponent = new LiferayUsersComponent(this); 
 // add to the page.  mainLayout.addComponent(usersComponent); 
 // switch to the list view for the initial view.  switchToListView();  } 
 /**  * switchToListView: Utility method to switch to the list view.  */  public void switchToListView() {  usersComponent.switchToListView();  } 
 /**  * switchToDetailView: Utility method to switch to the detail view.  * @param userId The user id to switch to.  */  public void switchToDetailView(final long userId) {  usersComponent.switchToDetailView(userId);  } 
 /**  * getThemeDisplay: Returns the current ThemeDisplay instance.  * @return ThemeDisplay The found instance.  */  public ThemeDisplay getThemeDisplay() { 
 ThemeDisplay td = null; 
 // okay, the theme display is actually a request attribute, so we just need to get there... 
 // start by getting the current portlet request  PortletRequest portletRequest = VaadinPortletService.getCurrentPortletRequest(); 
 // get the ThemeDisplay instance from the request attributes  td = (ThemeDisplay) portletRequest.getAttribute(WebKeys.THEME_DISPLAY); 
 // return the instance.  return td;  } } 

A couple of notes on this class...

We start with the @Theme annotation.  This informs Vaadin that the given Vaadin theme should be used for the UI and all of it's components.  Note this is the Vaadin theme, it is not a Liferay theme.  To see what Vaadin themes are available, you can use the Vaadin 7 Control Panel and use the Themes tab:

Vaadin Themes

This shows the list of Vaadin themes available for your Vaadin portlets.  Note that the liferay theme here does not mean the actual Liferay theme, it's actually a clone of the Liferay Classic theme in the form of a Vaadin theme (blue buttons, etc.).

The UsersUI has the two switching utility methods, these are just pass thru to the component with the tabs, but since they are in the UsersUI class they are available to all components in the app.

Finally there is the implementation of the getThemeDisplay() method.  This method accesses the current PortletRequest instance to extract the ThemeDisplay instance from the attributes.  Nothing magic here, but it is a useful routine to keep around.


After building and deploying the new portlet and dropping it in a page, you can see the results.

Here's the list view showing all active users:

Users Listing

And when you click on a user, you switch to the detail view:

Detail View

So I know what you're thinking - yuck.  It looks terrible.  Spacing is all weird, it's not at all colorful, it is just bland and boring.

And you're absolutely right.  But that is, of course, fixable.  I laid this thing out in a few hours, got the portlet working to the point where I could write this blog.  I did not spend any real time making it pretty, dealing with sizing of the view, etc.  But in a few additional hours, I could make it look pretty, make it look fresh and fine on a page.

The part that you don't see, the part that stands out - this thing rocks.  It is a full AJAX portlet.  Switching between the tabs is done entirely with JavaScript, there are no full page refreshes taking place.  I don't know of any other framework that is going to allow you to create a portlet like this in such a short amount of time that is all AJAX in the browser.


I hope this has been a useful introduction to Vaadin portlets.  It really doesn't do Vaadin justice, IMHO.  Like I said, the rendered views look pretty boring right now.  It doesn't take advantage of all of the Vaadin widgets available in the standard widgetset or any of the visual widgets available as Vaadin Add Ons.  It does however demonstrate how you can code an AJAXy portlet using only Java (there was no javascript in this example, there aren't separate pages as JSP, JSF, velocity templates, etc).  And if you're building business apps (where eye candy is not as important as getting the functionality done and out the door), this portlet may look just fine to you.

I think I will come back to this portlet in a future blog entry and address how it looks.  That will give me a chance to introduce creating custom Vaadin themes, accessing browser details for sizing, and making the view look good.

I have loaded the project into my own github account, you can access it from here:  Feel free to clone it, fork it, modify as you'd like.  Heck, I might even take pull requests if I get any.

If you have the Vaadin 7 Control Panel installed and you've deployed the LazyPagedContainer Add On, you can download and deploy the vaadin-sample-portlet-1.0-SNAPSHOT.war file directly from this blog.

Thanks for the post! Very helpful. Can Vaadin portlets be instanceable? If I put 2 of the same Vaaadin 7 portlets on the same page, 1 of them displays correctly and the other one throws an exception.

Caused by: java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(
at java.util.concurrent.locks.ReentrantLock.unlock(
at com.vaadin.server.VaadinSession.unlock(
at com.vaadin.server.SynchronizedRequestHandler.handleRequest(
at com.vaadin.server.communication.PortletBootstrapHandler.handleRequest(
at com.vaadin.server.VaadinService.handleRequest(

I am using Liferay 6.2 and Vaadon 7.6.

Hi, I have the same problem with adding more than one vaadin portlet in the same page. Did you fix the error?

Since the stack points to an issue inside of the VaadinSession, you'd probably need to customize the class to work around the issue.  This is a common issue for frameworks that are not "portal aware", they often never consider ramifications of having two of the same thing running inside of a single page.

Thanks for the informative post.
Since ajaxable has to be set to false for all vaadin portlets, is there a workaround to render a page before rendering the (vaadin) portlet?

The vaadin portlet which I use for multiple functionalities takes longer to load hence the page too. Is there way I can render the page first and then the portlet.

Thank you.