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 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?