Introduction to Converting Providers to Portlets

There are numerous differences in the way portlets and providers generate content for the desktop. In order to perform a successful conversion, the user must first understand the portlet request handling sequence. The ability to access user preferences and LDAP attributes from the portlet is vital to generating the correct content.

Converting JavaServer Pages^TM (JSPs) and tag libraries is the next step. JSPProvider-based JSPs and taglibraries need extensive reworking to function within the portlet framework. There is no need for a tag to wrap all the content; so all references to <dt:obtainChannel channel="$JSPProvider"> can be removed. All taglibraries specific to the desktop (desktop.tld, desktopProviderContext.tld) should be removed from the JSP and replaced with portlet taglibraries. Unfortunately, very few of the desktop taglibraries have portlet counterparts. The generic portlet taglibrary (portlet.tld in http://java.sun.com/portlet) has a number of useful tags. There are no handles to the portlet object available to the JSP, unlike providers. Any objects that need to be shared between external JSP and/or servlets and the portlet should be stored in the session at the application scope.

Note that there is no functionality present in the GenericPortlet abstract class to convert a template-based provider, other than the ability to use HTML files for each portlet mode.

Packaging, deploying and testing the new portlet are the last steps in this process. Portlets are deployed in a custom web-app. This means all JAR files, JSPs, templates, servlets, and properties files that the portlet uses must either be included or defined in the portlet deployment descriptor file (portlet.xml) or the web application deployment descriptor file (web.xml). A WAR file is created that contains all the files and information needed to deploy the web-app. The psadmin deploy-portlet command can be used to deploy the WAR file to the web container.