Troubleshooting Portlets

Owned by Jen Bourey
Last updated: Dec 08, 2010Version comment
2 min read

Common Portlet Issues

"Unable to retrieve portlet descriptor" error

Example
Dec 8, 2010 1:39:58 PM org.apache.pluto.core.PortletContextManager getPortletDescriptor
WARNING: Unable to retrieve portlet descriptor: '/CourseSchedulePortlet/course-schedule'

Common causes of this error include the following:

  • The portlet application context or name are configured incorrectly in the uPortal-side portlet registration
  • The portlet was not properly run through the plutofication routine
  • The portlet's context did not start up properly due to an error in the portlet's configuration

"Pre-existing session required" error

Example
11:51:09,376 [TP-Processor3] DEBUG servlet.DispatcherServlet - Could not complete request
org.springframework.web.HttpSessionRequiredException: 
       Pre-existing session required but none found

This error often occurs in portlets that make use of the AjaxPortletSupport library when Tomcat is not configured to share information between portlet and servlet sessions. Please see the documentation on setting emptySessionPath="true" in Installing Tomcat.

Interactive debugging

Interactive debugging with the Sysdeo Tomcat Plugin

Many uPortal developers use the SysDeo Tomcat Launcher plugin for Eclipse. This plugin is available at http://www.eclipsetotale.com/tomcatPlugin.html.

It can start/restart/stop Tomcat from buttons in Eclipse, automatically configures debugging and does its best to do hot-deploy (though some turn this off as they find it causes more problems than it solves). uPortal developers have been using it since the beginnings of using Eclipse with uPortal and are still using it with Eclipse 3.3.

Interactive debugging with Eclipse WTP

Other uPortal developers have had success using Eclipse WTP to launch Tomcat (which autoconfigures debugging if you start in the mode) but unchecking the options to deploy projects, and using Ant or Maven to deploy. The disadvantage is you lose the hot-code deploy you would get in a full Eclipse WTP integrated process, but it is slightly simpler than manually configuring the remote debugger connection. Having the tomcat console appear in Eclipse so you can click on hyperlinks in stack traces is a nice plus too.