By Anatoly Ivanov, Sibers Java Team Leader
Liferay Portal, which we have already announced and are using for our Java projects, as any application presents certain difficulties, which you may have encountered. Interested in our practices on how to make it work correct? This is what I come up with.
1. Filters
Portlet container should completely emulate servlet container work, namely wrap each request with filters. In fact, it initializes servlet filters, but only one in two or even more is activated each time (without noticeable regularity). It is due to the transaction per request approach, where the beginning of every request starts a transaction with the base and when the request is over, the transaction commits in the absence of any exceptions. Such an approach allows canceling any changes in the base during the current request (for example, in case of exceptions) as the portlet didn’t fix them and the database didn’t update with conflicts in different requests. Besides, without filters updating work with hibernate in the portlet, the session regularly failed.
Way out: Using subproject apache bridges (portlet filters) with working filters for the portlet. The problem is that portlet specification makes no provision for such filters on the supposition of servlet filters working correctly.
2. Myfaces bugs
The library is not fully debugged and sometimes digresses of the JSF specification, which results in time consuming looking for ways to do without bugs or changing to new library versions.
3. Debugging
Debugging under Liferay is quite awkward as it takes much time to start or shutdown the server, redeploy it, etc. Debugger can’t get involved and the search for problems is quite a task.
4. Liferay bugs
Liferay itself is not free of bugs. For instance, it doesn’t always form application classpath correctly, which leads to its malfunctioning. Sometimes Liferay goes into mysterious loops.
5. Changing library versions
This change may cause fall of jobsites because of the library’s bugs or its conflicts with other libraries.
6. JFS Porting
JFS porting for the portal is still an experimental area. As Lifray doesn’t provide standard compatibility means and portlet and JFS have different life cycles, an interlayer is essential for correct work.
Way out: In order to launch our JFS project under Liferay Portal, we are using an exterior project Tomahawk Bridge (http://palab.blogspot.com/) and its library. After lowering the version of myfaces–core till 1.1.4.1 there appeared some bugs in representation and navigation. However, developers are aware of these problems and are working on compatibility. In general, Liferay is starting to develop towards JFS compatibility.
Moreover, with JFS specifications satisfied, the project can work almost anywhere and be independent on the container. In our case JFS can be debugged in the frameworks of Tomahawk, which minimizes the time.
Hi Anatoly. Any comments on rendering speed, have you got tips on improving it?
Also comment on debugging, why do you have to restart the portal if you can just re-deploy the portlet. While portal restart may take up to 5 minutes depending on system size, so why not to use portlet hot-deployment?