+

Search Tips   |   Advanced Search


Overview

Get an overview of the IBM portlet API. This API is deprecated and this topic is provided only to support portlets that have not been converted to the standard portlet API.

The abstract Portlet class is the central abstraction of the IBM portlet API. The Portlet class extends HTTPServlet, of the Servlet API. All portlets extend this abstract class indirectly, and inherit from HttpServlet, as shown:

...   +--javax.servlet.http.HttpServlet
         |
         +--org.apache.jetspeed.portlet.Portlet
               |
               +--org.apache.jetspeed.portlet.PortletAdapter
                    | 
                    +--com.myCompany.myApplication.myPortlet       

Therefore, portlets are a special type of servlet, with properties that allow them to easily plug into and run in the portal server. Unlike servlets, portlets cannot send redirects or errors to browsers directly, forward requests, or write arbitrary markup to the output stream.

Generally, portlets are administered more dynamically than servlets.

The following updates can be applied without having to start and restart the portal server:

The portlet container relies on the J2EE architecture implemented by WAS. As a result, portlets are packaged in WAR files similar to J2EE Web applications and are deployed like servlets. Like other servlets, a portlet is defined to the appserver using the servlet deployment descriptor (web.xml).

This file defines the portlet's class file and read-only initialization parameters.

The following figure shows a portlet after its WAR file is deployed.

For each portlet deployed on the portal server, it creates a servlet, or portlet class instance, on the appserver.

The initialization parameters are set by the portlet developer and can be read by the portlet using the PortletConfig object.

The servlet deployment descriptor can contain multiple Web applications, each defined by the <servlet> element. In addition, each servlet definition can point to the same portlet class file, thus creating different PortletConfig objects with different initialization parameters for each portlet class instance. For more information, see Web application deployment descriptor.


Related information


Parent topic:

IBM Portlet API