Migrate A Portlet

The Portlet API of WebSphere Portal 4.1 is changed to be consistent with the J2EE specification. All servlets are extended from the HTTP servlet class of the servlet API and deployed as servlets. To deploy A Portlet of WebSphere Portal Server version 1.2 or 2.1, read the following sections to determine how to migrate the Portlet to use the new Portlet API.

• Change to the Portlet API
• Migrate Java source code
• Migrate JSP
• Migrate the Portlet deployment descriptor
• Migrate the Portlet package

Change to the Portlet API

To provide function enhancements and move the Portlet API to standard API implementation, IBM has updated the Portlet API. Some new APIs in WebSphere Portal 4.1 are highlighted as follows:

• Comply with J2EE specifications
• Tighter integration with Application Servers
• Enhanced Portlet message passing. Now the Portlet can useDefaultPortletMessageClass sends a message to a Portlet in another Portlet application. The message sent from the Portlet and the message received from the Portlet must be on the same portal page.

Change the following classes and methods:

Class	Method	Change	Note
Event	Getportlet ()	Deprecated	See event javadoc
Portletconfig	Getattribute ()	Changed	Use getinitparameter ()
Portletcontext	Send	Deprecated	See portletcontext javadoc to obtain a new method signature.
Portletdata	Removeallattributes ()	Deprecated	No replacement
Portletrequest	Getuser ()	Added
Portletrequest	Getportletsettings ()	Added	Portletsettings is the configuration data of the Portlet. Portletdata is still the place where user settings and values are stored.
Portletrequest	Getsession ()	Changed	Now getportletsession ()
Portletresponse	Encodeuri ()	Deprecated	Use encodeurl ()
Portletresponse	Getcharacterset ()	Deprecated	Use getcharacterencoding ()
Portletsession	Getuser ()	Deprecated	Use portletrequest. getuser ()
Portletapplicationsettings		Added	Manage the settings of the Portlet application updated by the portal Administrator
Portletsettings		Added	Manage the Portlet settings updated by the portal Administrator
Saxportlet		Removed	This type is no longer supported.

Manage Portlet configuration data

In earlier versions,PortletRequest,PortletResponseAndPortletSessionDiscrete objects that do not inherit from their servlet variant objects. In WebSphere Portal 4.1, these objects are directly inherited from their servlet variant objects, as shown below:

WebSphere Portal V1.2 and V 2.1		WebSphere Portal v4.1
		Portletcontext	Set by developers: Read-Only
Portletcontext
		Portletapplicationsettings	Initially set by developers: Administrator change
		Portletconfig	Set by developers: Read-Only
Portletconfig
		Portletsettings	Initially set by developers: Administrator change, read/write.

In previous versionsPortletDataData is stored during the processing of objects and Portlet events. In version 4.1, A Portlet can be stored inPortletDataValue stored in the object. If the Portlet does not try to update these values in editing mode, an exception occurs. See the Portlet API for details about these objects.

Migrate Java source code

The Portlet interface is replaced by an abstract Portlet class. The abstract method of the Portlet class has been changed, and any changes to the Portlet that directly extends the class need to be made. However, the Portlet class should not be directly inherited from the Portlet class. Instead, the Portlet should extend helper classes, such as abstractportlet, mvcportlet, or portletadapter. Maintain the methods and signatures of these classes across the release versions of the portal.

You do not need to migrate an instance or an extended Portlet of an existing Portlet, or A Portlet created using a cropped Portlet.

Access user topic

The JAAS user topic search has been changed. In WebSphere Portal Server 2.1, the Portlet obtains a reference to a user topic to access user security information.

  PortletSession session = portletRequest.getSession();  // Get the Portlet Session  org.apache.jetspeed.portletcontainer.UserImpl          // Get the User Object     user =(org.apache.jetspeed.portletcontainer.UserImpl) session.getUser();  Subject subject = user.getSubject();                   // Next, grab the Subject

In WebSphere Portal 4.1PortletContextThe access topic. The following example shows how to obtain the reference of a topic:

import org.apache.jetspeed.portlet.*;  import com.ibm.wps.portletservice.credentialvault.CredentialVaultService;  import javax.security.auth.Subject;  PortletContext         context = this.getPortletConfig().getContext();  CredentialVaultService service = (CredentialVaultService) context.getService(CredentialVaultService.class);  Subject userSubject = service.getUserSubject(portletRequest);

Once a user topic is referenced, the user creden。 and other theme information can be retrieved. For more information, see Portlet security.

Compute request, response, and Session Object

In earlier versions,PortletRequest,PortletResponseAndPortletSessionAre discrete objects and do not inherit their servlet variant objects. You may need to calculate one of these Portlet objects in the Portlet as follows:

  HttpServletRequest httpRequest = ((PortletRequestImpl) request).getServletRequest();  HttpServletResponse httpResponse = ((PortletResponseImpl) response).getServletResponse();  HttpSession hSession = ((PortletSessionImpl) session).getHttpSession();

In WebSphere Portal 4.1, these objects inherit from their servlet variant objects, as shown below.

Portlet object	Servlet object
Portletsession	Httpsession
Portletrequest	Httprequest
Portletresponse	Httpresponse

Since the Portlet object is a direct child of the servlet object, it does not need to be computed to derive the servlet object. Only use objects directly.

 PortletSession  myPortletSession = request.getSession(); String  myServletID = myPortletSession.getID();  // HttpSession.getID() 

Migrate JSP

In earlier versions, the Portlet container redefined some standard JSP tag semantics called through the portletcontext. Include method in JSP. For example, for <JSP: usebean scope = "request">, the bean is stored in portletrequest instead of httpservletrequest.

For WebSphere Portal 4.1, the tags in the JSP 1.1 specification are processed as defined in the Specification, even when running in the context of the Portlet container. The Portlet JSP tag library has been changed. <Encodeuri> the flag is canceled. Use the encodeurl () method of portletresponse. See use the Portlet API tag to obtain complete information.

Migrate the Portlet deployment descriptor

Currently, the Portlet is encapsulated as the following J2EE model of the Web application, so the deployment descriptor needs to be attached. The Web application deployment descriptor contains the information necessary to identify the Portlet as a servlet in the Web application. The servlet identifier is mapped from the href attribute marked by <Portlet> to the Portlet In the Portlet deployment descriptor.

In addition, according to the introduction of specific Portlet and specific Portlet applications, the Portlet deployment descriptor has also been changed. Each <Portlet> tag in the Portlet application still contains the <Portlet-Name>, <allows>, <cache>, and <supports> tags. Move the <default-locale>, <language>, and <config-param> labels to define a specific Portlet. <Context-param> is part of the <concrete-Portlet-app> element. This allows a Portlet to be configured in multiple ways without creating multiple Portlet instances.

See deployment descriptor for more information.

Migrate the Portlet package

The Portlet is now encapsulated in the war file. In the case of minimum values, you need to re-encapsulate the Portlet. The directory structure in the Portlet war is consistent with that in the J2EE Web application. In earlier versions, protected resources such as Java classes and jar files are stored inPORTLET-INFDirectory. Protected resources are now stored inWEB-INFDirectory.

For more information, see encapsulate and deploy a Portlet.