Somehow, it seems the portlet class does not receive the requests from the client side engine. Maybe the requests point to the wrong location in this case.
The configuration parameters on the HTML page generated by the portlet could provide some clues - these can be seen e.g. with FireBug, the interesting part is the javascript block that sets up the variable vaadin.vaadinConfigurations . These parameters tell, among other things, where the client side engine should send various requests.
Note also that in a portlet 2.0 project, no servlet is really needed if you serve the resources statically - a web.xml file is generated to make it easier to test the application as a servlet, and potentially to serve resources.
You could put the VAADIN folder in a shared (preferably statically served) directory on the portal, and set up the path to it. On portals other than Liferay, this is looked up in the context property “vaadin.resources.path”, but I don’t know how to configure than on WebSphere. If necessary, you could even override AbstractApplicationPortlet.getPortalProperty() to handle this case. If the servlet is used to serve the resources and does not cause any conflicts, you could make it only serve /VAADIN .
It was my fault, I used Vaadin Portlet V1 and Vaadin Portlet V2 on the same page and that seems to be the problem, If I stick to the same version per portal page there is no problem…
Ernst, could you please share the example? I have been trying to get vaadin to work as Portlet 2.0 in Websphere portal but can’t get it to work. It just displays an empty portlet…
You can get a Vaadin JSR 286 portlet to run on WebSphere by completing these tasks (I tested on WPS 7.0):
create a new class that extends com.vaadin.terminal.gwt.server.ApplicationPortlet2 (example attached)
edit the portlet.xml (use your new class, apply the widgetset, set your theme)
In the portlet class I had to overwrite getStaticFilesLocation(PortletRequest request) to let vaadin find the widget resources. The default (/html) will work for Liferay but not for WPS.
The getThemeURI Method was overwritten, because Vaadin keeps trying to load the default theme “Reindeer” instead of my custom theme. I configured the theme as a portlet init parameter in the portlet.xml file.