Building bedework for liferay(4)
The bedework web client is intended to work as a jsr168 client. There seems to be a little more work needed but here's how it was done for liferay4.
Liferay version installed
I downloaded and installed the jobss + tomcat version of liferay which unpacked into the directory
We can refer to this as JBOSS-HOME
After some PermGen? space errors I tried running it under Java6. This seemed to work OK and the errors went away without any extra configuration.
Most of the properties are the same. The liferay changes are mostly in the global settings. I had problems running using the hsqldb database which may have been driver version errors. Jboss uses hsql for persistance of objects so I switched to mysql.
I commented ot the standalone section
# These for standalone and for j2ee #org.bedework.global.servlet.class=org.apache.struts.action.ActionServlet #org.bedework.global.ignoreContentType=false #org.bedework.global.portlet.mapping= #org.bedework.global.genurl.taglib.tld=struts-html.tld
and uncommented the liferay4 section
# These for liferay 4 org.bedework.build.for.liferay4=yes org.bedework.global.portal.platform=liferay4 # servlet-class is the action servlet in web.xml org.bedework.global.servlet.class=com.liferay.util.apache.bridges.struts.LiferayPortletServlet # portlet-servlet.class is the servlet-class element for the portlet servlet in web.xml org.bedework.global.portlet-servlet.class=com.liferay.portal.kernel.servlet.PortletServlet # portlet.class is in portlet.xml and the value for the portlet-class init par in web.xml org.bedework.global.portlet.class=org.apache.portals.bridges.struts.StrutsPortlet # portal-servlet.context.provider is in portlet.xml org.bedework.global.portal-servlet.context.provider=com.liferay.util.apache.bridges.struts.LiferayServletContextProviderWrapper org.bedework.global.portal-servlet.context.listener=com.liferay.portal.kernel.servlet.PortletContextListener org.bedework.global.ignoreContentType=true org.bedework.global.genurl.taglib.tld=bedework-portlet-struts-html.tld org.bedework.global.liferay.company-id=liferay.com
It may be possible to get this working for liferay3 by changing some of those values above.
In addition you need to set the portlet name for each application:
... org.bedework.app.CalAdmin.portlet.name=CalAdmin ... org.bedework.app.UserCal.portlet.name=UserCal
and it seems that the web.xml display-name element is used by liferay and needs to be set to the same as the portlet-name, e.g.
... # display.name has to be same as portlet name for liferay? org.bedework.app.UserCal.display.name=UserCal ...
With those changes in place you should be able to build the portlet.
I have had problems using the auto-deploy feature of liferay and uportal. I believe the problem resides in the tool which maniupulates the web.xml file and I think this tool is in both cases a modified version of the pluto tool.
It has problems with the multiple servlet-mapping elemnts and loses all but one of them.
The build process builds the web.xml as it would have been built by the deployer tool so it can be dropeed straight into the correct directory.
In the case of the jboss system, this directory is JBOSS-HOME/server/default/deploy
For this release of liferay, the directory is JBOSS-HOME/server/default/deploy/liferay-portal.ear/portal-web.war
For example, for the personal calendar portlet you will need to copy out of the quickstart tomcat webapps directory the following:
- ucalrsrc (if you want to try the standalone application as well)
If you are switching databases, build the new database as set out in the deployment manual.
I ran under Java6 (eventually). set JAVA_HOME, cd to JBOSS-HOME/bin and do "./run.sh"
In your browser go to localhost:8080 and login as email@example.com with password test.
Click on the "add content" link, open the "Test" tab and add "UserCal".
If all went well, you'll (eventually) see the user calendar displayed as a portlet - a little cramped for space perhaps.
At the moment pop-up windows are not working correctly, which makes it difficult to add events. Currently we need to select the calendar and I believe this should be a resource url, flagged by the "gdo" suffix.
In a production environment we would probably have a different set of stylesheets for the portal version. This is why the resource name is suffixed by ".liferay4". It allows multiple sets of stylesheets for a single application. Currently I have gone back to loading the same version as the standalone application.