之前一个项目是做一个政府的门户,用的是JBoss Portal作为portlet容器。项目一期结尾,客户要求所做的portlet能在Liferay上跑,经过R&D之后,觉得这个几乎是不能完成的任务。
项目里用的bridge: JBossPortletBridge,它可以很好的JBoss Portal结合,对于Liferay却显得无能为力。JBoss Portal支持richfaces存在问题,当一个页面存在多个portlets的时候,会有badpadding的异常,所以项目里并没有用a4j的 东西。如果把这些portlets放到Liferay里面,<h:commandXXX/>是不起任何作用的,
<a4j:commandXXX/>才能帮到忙。还有很重要的一点
,需要得到正确的javax.servlet.include.path_info。
这类的资料晚上很少,经过N久的努力,找到一个很有用的article,网址如下:
http://java-ua.blogspot.com/2008/10/richfaces-jsf-ri-jbossportletbridge.html
主要内容摘录如下:
The task to make few portlets for Liferay 5.1 Portal using RichFaces + JSF RI looks trivial. But it isn't.
There are few decisions:
I choosed the second with understanding that JBossPortletBridge is in beta and everywhere says that it supports JBossPortal, but I did not find where says - "It supports Liferay too". It does not support Liferay Portal 5.0 .
I found few interesting things, that anyone should know before starting write portlets with RichFaces for Liferay using JBossPortletBridge 1.0.x Beta:
javax.portlet.faces.GenericFacesPortlet
given with JBossPortletBridge. You'll need manually setup the request attribute javax.servlet.include.path_info
with correct viewId you want to process and render. Or you can setup this request attribute at the PortletExternalContextImpl
class in calculateServletPath()
method (remember JBossPortletBridge 1.0.x Beta). <a4j:commandXXX/>
components to process navigation. <h:commandXXX/>
will not help ((.
虽然大家都遵循×××,但是通用性还是有很大区别的。项目不能依赖于所运行的容器,这个项目开始并没有考虑到要搬到另外一个portal容器,所以有些东西是和JBoss Portal戚戚相关的,这会为以后带来很多不必要的麻烦。最后终于把portlet在Liferay里面跑起来了,但是也仅仅是能出个界面,功能是用不了的。如果真的需要在这两个容器里面都可以跑,那还得有许多的东西去研究,因为a4j在JBoss Portal里有问题,而h:在Liferay里有问题。当然,换个bridge当另说,最理想的结果是JBossPortletBridge 支持Liferay了...