Hi,
We are trying to build custom portlets using the combination Vaadin - Liferay - Weblogic.
The Vaadin version is 6.4.8. The Liferay version is 5.2.2. The Weblogic version is 10.3.
When portlets are added to a page, they do not display any content.
The server log displays:
####<7-dec-2010 12.26 u. CET> <[ACTIVE]
ExecuteThread: ‘2’ for queue: ‘weblogic.kernel.Default (self-tuning)’> <> <> <> <1291721219510> <Could not deserialize session data.
java.io.NotSerializableException: javax.portlet.PortletMode
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at java.util.HashMap.writeObject(HashMap.java:1000)
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at weblogic.common.internal.PassivationUtils.toByteArray(PassivationUtils.java:33)
at weblogic.common.internal.PassivationUtils.toByteArray(PassivationUtils.java:24)
at weblogic.common.internal.PassivationUtils.copy(PassivationUtils.java:64)
at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java:100)
at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java:44)
at weblogic.servlet.internal.session.SessionData.getAttribute(SessionData.java:401)
at com.liferay.util.servlet.SharedSessionWrapper.getAttribute(SharedSessionWrapper.java:68)
at com.liferay.portlet.PortletSessionImpl.getAttribute(PortletSessionImpl.java:111)
at com.liferay.portlet.PortletSessionImpl.getAttribute(PortletSessionImpl.java:98)
at com.liferay.portlet.PortletSessionImpl.getAttributeMap(PortletSessionImpl.java:130)
at com.liferay.portlet.PortletSessionImpl.getAttributeMap(PortletSessionImpl.java:119)
at com.liferay.portal.servlet.taglib.portlet.DefineObjectsTagUtil.doStartTag(DefineObjectsTagUtil.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.liferay.portal.kernel.util.MethodInvoker.invoke(MethodInvoker.java:180)
Does anyone have a clue about how to solve this issue?
Just guessing, but maybe you have serialized some old version of your application sessions and now try to deserialize them. Try to flush serialized sessions and see if it works.
Do you get any vaadin -related classes on any stack -trace? Is there a possibility that this is not related to Vaadin? Try to add some other portlet to the page.
Non-vaadin based portlets can be added to the page.
The first strange thing is that there is no trace of any Vaadin related classes in the stack-trace.
The other strange thing is that the portlet behaves perfectly on Tomcat-Liferay.
Perhaps someone has a “hello world” portlet that runs on Liferay-Weblogic?
Any other suggestions are greatly appreciated.
Could it be that you are deploying some of the portlet API classes with your portlet. The API (portlet.jar) should be provided by the portal, and deploying different copies of the interfaces could cause problems.
Try to make hello world application without any dependencies and see if it works. If it works, then the problem could be in some of the libraries you include (maybe some of those, but different versions, are already included in the classpath by weblogic)
Thanks. I managed to get it working, by making some liferay classes implement Serializable.
This seems to be related to the issue mentioned.
The other thing I had to do is to remove “vaadin.jar” from the domain lib folder and add it only to the portlet war.
Is there any reason why it should be in the in the domain lib folder?
There should typically be one shared copy of vaadin.jar or the portal. This is because the static resources (widgetset and themes) on the portal need to match the version of Vaadin in use - and this also helps keep the portlet size down. You can refer to it in liferay-plugin-package.properties .
It is possible to include the Vaadin JAR in a portlet, but in that case I would recommend you name it “vaadin.jar” (removing the version number), as e.g. Tomcat does not clean up old JARs from the temporary or deployment directory when redeploying, sometimes leading to very hard to understand class loading issues. You would then also need to make sure the resources on the portal match the version of the Vaadin JAR.
Based on class loading concerns on different platforms, YMMV - I don’t really know Weblogic.