Further Learnings on Open Source Portals

It's been a while since I have updated this knowledge sharing blog as my developments and research into Liferay has been put on hold due to the end of my freelance project.
Thank everyone who have taken the interest and time to read, discuss and help me through my explorations of Liferay.
For anyone who wants to look deeper into Java open source portals, reading is always a good media. I, myself, have read many books in my life and I have benefited much from all the knowledge and wisdom of good writers.
Learn more of Java Portals, pick up a book now.

Task 3

Task:

• SSL
• Test cases for session timeout implemented in Task 2
• Change to a company-oriented GUI
• Fix task 2 bugs

Notes:

• Task 2 bug fixed.
• Found thread on SSL implementation here.
• Notes on startup interface - Login to Liferay as administrator and switch to Guest Community (in the upper right corner of the page). The application startup page is shown, and modifications can be made on the layout just like a logged in home page.

Task 2 bug fix

Bug

• My developed portlets refresh and somehow loses their sense of identity, rendering content of another portlet's.

Here's an example of what my portlet class is like:

public class BBPortlet extends StrutsPortlet {

public static final String DEFAULT_VIEW_ACTION = "/ext/bb/view";

public void init(PortletConfig config) throws PortletException {
super.init(config);

if (Validator.isNull(viewAction)) {
viewAction = DEFAULT_VIEW_ACTION;
}
}

}

I did read through the JSR-168 specs and was about to do a total revamp of my portlet classes when I realized this viewAction variable is nowhere declared. This if (Validator.isNull(viewAction)) line is actually quite standard across the struts portlets in Liferay and I had taken it for granted. What the heck, I tried commenting it out and did re-deployed. Voila! Everything works fine now and all the portlets are rendering the right content. Lesson learnt.

Task 2 - Milestone 2

Task:

• Authentication and Session Management
• variable session timeout for different user/groups
• 10min grains - no timeout
  
• one session only per loginID
• prompt for session overwrite
• User Login Management Portlet
• manage users' session time out
• tracks the users login/logout history
• force log out of users

Developed portlet for managing session timeout values so every user group would have a customizable timeout. Default timeout from properties will used if timeout for usergroup is not defined. Decided to allow free input of timeout instead of 10min grains. No point running a list, more flexible with a textfield. session_timeout.jsp has been modified to run a query to find the session timeout from DB instead of using default immediately.

Audit Trail module and search portlet done up.

Learnings

Managing Persistence with Liferay.

• Liferay's service builder is relatively simple to use. Just fill up service.xml and do a "ant build-service" to auto generate all the persistence classes. Update impl and model classes, run ant again, and you're done with the persistence classes. There's even a "ant build-db" to generate the sql scripts for the new tables. Comprehensive tutorial here.
• At times, there would be the need for custom queries that the service builder does not take care of. I've had the need to join tables for the query of user group session timeouts, and luckily enough, there's another comprehensive tutorial that enlightened me on this aspect. Here's the good stuff.

Bugs

• The hibernate DAO types provided by Liferay are incomplete and I had to do up my own TimestampType for the sake of my audit trail module. Why provide some types only and not all? Hope Liferay makes it complete on the next major release. Things should not be done halfway, eh?
• I was more of less done until I did my testing and found this crazy bug. My developed portlets refresh and somehow loses their sense of identity, rendering content of another portlet's. This is by far the biggest problem so far, and can any kind souls help me out. Please view my posting on Liferay developer forums. I'm currently reading up on JSR Specs to see what went wrong. :(

Met my boss anyway. I can't wait till the bug is fixed. It would just take too long. I'm ready for task 3.

Task 2 - Progress

Task:

• Authentication and Session Management
• variable session timeout for different user/groups
• 10min grains - no timeout
  
• one session only per loginID
• prompt for session overwrite
• User Login Management Portlet
• manage users' session time out
• tracks the users login/logout history
• force log out of users

One session per loginID is simply done by tweaking the portal properties file, portal-ext.properties
Here's the critical line to take note of. Makes very good sense actually.

auth.simultaneous.logins=false

To force log out of users would mean the kill session feature already implemented in the admin portlet. Another one down.

Now the variable timeout... hmm...

TIBCO sponsors DWR

TIBCO, The Power of Now, is sponsoring DWR development to enhance DWR and integrate DWR with TIBCO GI and TIBCO AM. Good move!

Full story here

Task 2

Task:

• Authentication and Session Management
• variable session timeout for different user/groups
• 10min grains - no timeout
  
• one session only per loginID
• prompt for session overwrite
• User Login Management Portlet
• manage users' session time out
• tracks the users login/logout history
• force log out of users

Challenges:

• every part of it...
  

Task 1 - Bugs

Here are some of the bugs which I managed to workaround eventually. I don't know if they were logical errors or liferay bugs though.

Bug #1 - Polling continues after portlet removal
So my portlet would poll the server every 3 seconds via AJAX, this is great, until I remove an instance of the portlet. The AJAX component, javascript obviously, would continue even though the portlet has been removed and I was bombarded by heaps of javascript errors every 3 seconds.

Wordaround
Check for existence of a field before polling. This is a logical workaround, but I would think that it is even more logical if the javascript stops work once the portlet is removed.

Bug #2 - Wrong forwarding to "portlet_not_setup"
Did a little testing and found this bug. 4 instances of portlet, 1 previously configured. After using the configuration setup for a 2nd portlet and saving, I was greeted with a shock. All 4 portlets were forwarded to the "/portal/portlet_not_setup" page. But 2 were actually set up, so what went wrong?

Investigation
After playing around with print statements, I realised that none of the portlets were forwarded to the view page. I don't get it. Here's the "before" code snippet.

String var = getVar(req, res);

if (Validator.isNull(var)){
return mapping.findForward("/portal/portlet_not_setup");
}

req.setAttribute("var", var);

return mapping.findForward("portlet.ext.testportlet.view");

The printlns tell me that they are actually going through the right loop and if the portlet instances had "var" configured, but they were just not forwarded to the view page. Everything was just mysteriously directed to the portlet_not_setup page even though the loop was not even traversed by the particular portlets.

Workaround
Forwarding everything to "view" as a workaround now. It shouldn't be this way, but I had to make things work. Here's the "after" code:

String var = getVar(req, res);

//if (Validator.isNull(var)){
// return mapping.findForward("/portal/portlet_not_setup");
//}

req.setAttribute("var", var);

return mapping.findForward("portlet.ext.testportlet.view");

And there's now a check at the "view" page to realize the existence of the param "var", showing a message to ask for configuration if param is not found.


Any advice or comments on this, anyone?

Task 1 - Milestone 1

AJAX

After reading several articles on how easy it is to implement AJAX with DWR, I decided to give it a try.

"DWR allows Javascript in a browser to interact with Java on a server and helps you manipulate web pages with the results."

True enough, with sufficient knowledge of javascript, working AJAX with DWR was like snatching candy from kids.

It only took 3 pages of DWR reading to achieve my task 1 AJAX objectives:

• GETTING STARTED WITH DWR
• DWRUtil.setValue()
  
• engine.js
  

The simple AJAX implementation with DWR also allowed polling and updating of my portlet to be done with just a if(true) loop with a setTimeOut().

Multiple Instances of Portlet

Googled for how to develop portlets which allowed multiple instances, but to no avail. So posted a msg to the liferay forums.

Add this tag true to the portlet configuration in liferay-portlet-ext.xml.

Simple as that.

Time to meet my boss.

NEWS: InfoWorld 2007 Technology of the Year Awards: Liferay Wins for Best Open Source Portal!

"Liferay Portal 4.0 rivals many commercial portal platforms in both functionality and technology. Liferay permits separate portals for different business units, and you can hot deploy any JSR 168 compliant portlet..."

Read full article here.