Redeploy Vaadin Portlet gives error

When I redeploy a new version of my vaadin portlet in LIferay using the same version of Vaadin, I get the following error when I try to access the portlet.

18:08:55,692 ERROR [jsp:164]
java.lang.ClassCastException: com.vaadin.terminal.gwt.server.PortletApplicationContext2 cannot be cast to com.vaadin.terminal.gwt.server.PortletApplicationContext2
at com.vaadin.terminal.gwt.server.PortletApplicationContext2.getApplicationContext(
at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.getExistingApplication(
at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.findApplicationInstance(
at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.handleRequest(
at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.doDispatch(
at javax.portlet.GenericPortlet.render(
at com.liferay.portlet.FilterChainImpl.doFilter(
at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(
at com.liferay.portal.kernel.servlet.PortletServlet.service(
at javax.servlet.http.HttpServlet.service(
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
at org.apache.catalina.core.ApplicationDispatcher.invoke(
at org.apache.catalina.core.ApplicationDispatcher.doInclude(
at org.apache.catalina.core.ApplicationDispatcher.include(
at com.liferay.portlet.InvokerPortletImpl.invoke(
at com.liferay.portlet.InvokerPortletImpl.invokeRender(
at com.liferay.portlet.InvokerPortletImpl.render(
at org.apache.jsp.html.portal.render_005fportlet_jsp._jspService(
at org.apache.jasper.runtime.HttpJspBase.service(

If I restart Liferay (tomcat), it all works. Any ideas?

Two different classloader instances are loading the same class, and the results are not compatible with each other. Most likely there are open sessions containing references to instances loaded with the old classloader of your previous deployment.

Are you using a shared copy of the Vaadin JAR on the portal?
Do you have a copy of the Vaadin JAR in your WAR?

The recommended configuration would be to deploy the Vaadin JAR on the portal and refer to it in WEB-INF/ (“portal-dependency-jars=vaadin.jar”). To avoid having the same classes multiple times in the classpath, you should then not deploy the Vaadin JAR in your WAR but just point your development environment classpath to a copy of it (preferably the one in your Liferay installation).

Also, do note that deploying a new version of a WAR on Liferay e.g. on Tomcat doesn’t clean old, no longer user versions of JARs. Therefore, you might still have an old copy (or multiple) of the Vaadin JAR even though your WAR no longer contains it. Having multiple copies of the Vaadin JAR in your webapp deployment directory is another potential culprit.

Which Vaadin and Liferay versions are you using? In the future, the Vaadin JAR and resources will be bundled and pre-configured in Liferay 6.0, hopefully reducing the occurrence of such problems.

I have a copy of the vaadin.jar file in the ROOT/WEB-INF/lib (Liferay) directory and in my portlet WAR. I am using Liferay 5.2.3 and Vaadin 6.2.4 and Tomcat 6.

I removed the vaadin jar from my portlet WAR and used “portal-dependency-jars=vaadin.jar” in the WEB-INF/ file. Using this method, Liferay still deploys the vaadin jar file from the portal to my portlet’s WEB-INF/lib directory. When I redeploy my portlet, I still get the following exception.

java.lang.ClassCastException: com.vaadin.terminal.gwt.server.PortletApplicationContext2 cannot be cast to com.vaadin.terminal.gwt.server.PortletApplicationContext2

Do I need to just have one copy of vaadin.jar in the common lib dir of tomcat? So maybe use the common class loader and not have vaadin.jar in ROOT/WEB-INF/lib or in my my portlet WAR file?

I have the same problem here, have you find a solution?

No solution yet. Still have the same problem.

I have this problem how is the solution!?

for me a “magical solution” was to remove the portlet from that page (close button) and re-add the same portlet…

now all works, but i know this was some “fortunate/magical” situation because dunno what the real problem was …

Have you disabled private session attributes? See
this post