The portlet API of WebSphere Portal version 4.1 changes to the J2EE specification. All portlets are extensions from the HTTPSERVLET class from the Servlet API and put all portlets as a servlet. If you want to deploy the portlet of WebSphere Portal Server version 1.2 or 2.1, read the following chapter to determine how to migrate portlets to use the new portlet API.
Change to Portlet API Migration JAVA Source Code Migration JSP Migration Portlet Deployment Descriptor Migration Portlet Package
Change to Portlet API
To provide functional enhancements and move the portlet API to standard API implementation, IBM updates the portlet API. Some new APIs in WebSphere Portal 4.1 include:
Compliance with the J2EE specification is more closely integrated with the application server to transmit the enhanced portlet message. Now Portlets can send messages in other portlet applications using the DEFAULTPORTLETMESSAGE class. Send portlet messages and messages that receive portlets must be on the same portal page.
The following classes and method changes:
Class method to change the comment EventgetPortlet () Deprecated see Event JavadocPortletConfiggetAttribute () Changed using getInitParameter () PortletContextSendDeprecated See PortletContext Javadoc to obtain a new method signature PortletDataremoveAllAttributes () Deprecated no replacement PortletRequestgetUser () Added PortletRequestgetPortletSettings () AddedPortletSettings configuration data portlet. PortletData is still a place where the user settings and values are stored. PortletRequestgetSession () Changed Now getPortletSession () PortletResponseencodeURI () Deprecated use encodeURL () PortletResponsegetCharacterSet () Deprecated use getCharacterEncoding () PortletSessiongetUser () Deprecated use PortletRequest.getUser () PortletApplicationSettings Added to manage updates by the portal administrator to set portlet application PortletSettings Added Manage the portlet settings of the portal administrator update SaxportLet Removed no longer supports this class.
Manage portlet configuration data
In earlier versions, PortletRequest, PortletResponse, and portletations refer to discrete objects that do not inherit from their servlet variant objects. In WebSphere Portal 4.1, these objects are inherited directly from their servlet variant, as follows:
WebSphere Portal version v1.2 and v 2.1 WebSphere Portal V4.1 portletContext by developer settings: read-only portletContext portletApplicationSettings initial by developer settings: Change portletconfig by the administrator: read-only portletconfig portletsettings initial setup : You can change, read / write by administrator. In previous versions, the portlet in the view mode can store data during the portletdata object and the portlet event processing. In Version 4.1, portlets can store values in the portletdata object only when portlets are editing. If the portlet does not attempt to update these values in the editing mode, exceptions will occur. See the portlet API for more information on these objects.
Migrate Java source code
The portlet interface is replaced by an abstract portlet class. The abstract portlet class has been changed and changes to any portlets that directly extend the class directly. However, portlet should not inherit from the portlet class. Instead, the portlet should extend the help class such as Abstractportlet, MVCPortlet, or PortletAptapter. The distribution of the portal maintained the methods and signatures of these classes.
Examples or extensive portlets of existing portlets, or portlets created with crop portlets do not need to be migrated.
Access user theme
The search of the JAAS user topic has changed. In WebSphere Portal Server 2.1, portlets access users' security information by getting a reference to the user topic.
PortletSession session = portletRequest.getations (); // 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.1, access the user topic from PortletContext. The following example demonstrates how to get a reference to the user 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 the reference is retrieved, the information of the user credentials and other information of the user subject can also be retrieved. For further information, see Portlet security. Calculate request, response, and session objects
In earlier versions, PortletRequest, PortletResponse, and portletations are discrete objects that 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) .gethtpSession ();
In WebSphere Portal 4.1, these objects are inherited from their servlet variant object, as shown below.
Portlet object servlet object PortletSessionHttpsessionPortletRequestHttpRequestportletretresponsehttpResponse
Since the portlet object is the direct child of the servlet object, it is not necessary to calculate the servlet object. Use only objects directly.
PortletSession myportletations = request.getations ();
String myservletid = myportletsssion.getid (); // httpsession.getID ()
Migration JSP
In earlier versions, the portlet container redefines the semantics of some standard JSP tags called through the portletcontext.include method. For example, for
For WebSphere Portal 4.1, the tags in the JSP 1.1 specification are processed as defined in the specification, even in the context running in the portlet container. The portlet JSP tag library has changed.
Migrate portlet deployment descriptor
Because the portlet is now encapsulated by the J2EE model as a web application, additional deployment descriptors are needed. The web application deployment descriptor contains the information necessary to identify the portlet as a servlet in a web application. The servlet identifies the portlet in the portlet deployment descriptor with the
Moreover, the portlet deployment descriptor has changed according to the specific portlet and the specific portlet application. Each
Migrate portlet software package
Portlet is now encapsulated in the WAR file. In the case of a minimum, you need to re-encapsulate the portlet. Directory structure in portlet war is consistent with the directory structure of the J2EE web application. In previous versions, such as the Protected Resource of Java classes and JAR files, stored in the / portlet-INF directory. Protected resources are now stored in the / web-infers.
To get more information, see Packaging and Deploying Portlets.
