This article offers guidance to migrating existing servlet Struts-based applications to portlet Struts-based applications - with a minimum of steps - using WebSphere Studio Application Developer v5.0 with the WebSphere Portal v5.0 test environment.

This article does not cover expanding the functionality of the Web application (e.g., using portlet communication), nor is it an introduction to Struts, WebSphere Portal, or portlet programming. The purpose of this article is to enable you - with the fewest changes possible - to run a servlet-Struts application as a portlet-Struts application in WebSphere Portal v5. For further information on portlet development, refer to the Portlet Development Guide.

In short, the abstract Portlet class is the central abstraction of the Portlet API. The Portlet class extends HTTPServlet of the Servlet API. All portlets extend the Portlet class indirectly, and inherit from HttpServlet. 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 forward requests, send redirects or errors to browsers directly, or write arbitrary markup to the output stream. Portlets are more dynamic than servlets - they can, for example, be installed or their settings can be changed without having to restart the Portal Server.

The portlet container relies on the J2EE architecture implemented by the WebSphere Application Server. 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 application server using the Web application deployment descriptor (web.xml). This file defines the portlet's class file, the servlet mapping, and read-only initialization parameters.

Exporting the Existing Application

1. If multiple projects exist for same application, merge all them into a single project.
2. Export the project to the file system as a WAR file with source files.

Import the Application into the Portal Project

1. Create a new portlet application project, specifying the Create empty portlet and J2EE Level 1.3 options.
2. Import the WAR file you exported earlier to the existing project and press Finish.
3. Turn off the Overwrite existing resources without warning option.
4. Answer No to Overwrite portlet.tld.
5. Answer Yes to Overwrite portlet.xml and web.xml.

Setup Environment for WebSphere Portal

1. Select your portlet project in the J2EE Navigator view.
2. Select File > Properties.
3. Select Java build path.
4. Make sure you have the definitions shown in Listing 1 inside the c:\<workspace>\<projectname>\.classpath file.

   Note the following:
   a. Make sure to check your classpath entries in the new Studio Products tooling after migration. Ensure that the classpath entries are pointing to the new WebSphere Portal v5.0 paths.
   b. When you create a portlet project for WebSphere Portal v5.0, you can choose WPS_V5_PLUGINDIR as a class variable.

5. Select File > Import File System.
6. Press Next.
7. Select the following directory as a source directory:

   <WebSphere_Studio_root>/wstools/eclipse/
   plugins/com.ibm.wps_v5_<WebSphere_Portal_version>

   For example: com.ibm.wps_v5_5.0.0 - where <WebSphere_Studio_root> is the root directory of WebSphere Studio and <WebSphere_Portal_version> is the specific 4.x version of WebSphere Portal.

8. Select the following directory as a target directory: <portlet_project>/Web Content/WEB-INF/tld - where <portlet_project> is the name of your project.
9. Override the existing portlet.tld file with the new one.

In WebSphere Studio, the Portlet Deployment Descriptor should be checked for this application (do you mean Struts 1.1 RC 1?) to verify that the Struts filter chain is specified. The filter chain is used to implement solutions for some of the differences between the versions of WebSphere Portal.

1.  The Struts application must be migrated to the newer version of the Struts Portlet Framework. Unzip the PortalStrutsBlank.war file located in the <wp_root>/dev/struts/Struts portlet directory. This is an actual Struts application, so the directory structure is similar to many Struts applications. Copy the following JAR files in the WEB-INF/lib directory from the PortalStrutsBlank.war to the WEB-INF/lib directory of the Struts application:

• commons-beanutils.jar
• commons-collections.jar
• commons-dbcp.jar
• commons-digester.jar
• commons-fileupload.jar
• commons-lang.jar
• commons-logging.jar
• commons-pool.jar
• commons-resources.jar
• commons-services.jar
• commons-validator.jar
• jakarta-oro.jar
• jdbc2_0-stdext.jar
• PortalStruts.jar (Struts Portlet Framework)
• PortalStrutsCommon.jar (Struts Portlet Framework)
• PortalStrutsTags.jar (Struts Portlet Framework - new)
• struts.jar
• StrutsUpdateForPortal.jar (Struts Portlet Framework)

2.  Remove the following files from the WEB-INF/lib directory, they exist:

• commons-services.jar
• jdbc2_0-stdext.jar
• commons-dpcp.jar
• commons-pool.jar
• commons-resources.jar

4.  Update the TLD files with the versions from the WEB-INF/tld directory of the PortalStrutsBlank.war. The TLD files that ship with the Struts Portlet Framework and should be used in the Struts application are listed here.

• struts-bean.tld
• struts-chtml.tld
• struts-html.tld
• struts-logic.tld
• struts-nested.tld
• struts-portal-html.tld
• struts-portal-wml.tld
• struts-template.tld
• struts-tiles.tld
• struts-wml.tld

6.  In WebSphere Studio, right-click on the project name and select Refresh so WebSphere Studio updates the project with the new library and property files.

Modifications Needed to Run in WebSphere Portal

Web Deployment Descriptor: web.xml
Most of the configuration for a Struts application is in the Web deployment descriptor file (web.xml).

1.  Define a unique ID for the Web application.

<web-app id="WebApp_1">
		...
	</web-app>

2.  Define the display name for the portlet.

<display-name>StrutsPortletUI</display-name>

3.  Change the <servlet-class> to com.ibm.wps.portlets.struts.WpsStrutsPortlet.

<servlet id="Servlet_1">
     <servlet-name>MyStrutsApp</servlet-name>
     <servlet-class>com.ibm.wps.portlets.struts.WpsStrutsPortlet
     </servlet-class>
     ...
 </servlet>

Note: The servlet ID should be suffixed with a unique ID to prevent conflicts with other portlets. Define a servlet ID for all the defined servlets inside web.xml.

4.  In a portlet, you need to use a servlet URL mapping for your portlet. You would typically use a path prefix servlet mapping:

<servlet-mapping id="Unique_ServletMapping">
  <servlet-name>Struts</servlet-name>
  <url-pattern>/Struts/*</url-pattern>
</servlet-mapping>

5.  A normal Struts application requires a servlet mapping to associate paths to actions. The Struts Portlet Framework handles this using a pseudo servlet mapping that needs to be specified as an init parameter:

<init-param>
  <param-name>struts-servlet-mapping</param-name>
  <param-value>*.do</param-value>
</init-param>

6.  The Struts application needs to specify what the initial screen is for the application.

<welcome-file-list>
  	<welcome-file>index.jsp</welcome-file>
 </welcome-file-list>

7.  The Struts Portlet Framework takes advantage of this module support to provide both mode and device (markup) differentiation of the Struts configuration. There are two paths that can be specified in the web.xml for supporting differentiation of modes and device types:

a.  The first is the search path, used to determine which module (and which struts-config.xml file) to use. It also determines the base directory for locating JSPs. The following init param setting will set the search path to consider markup name and mode when searching for modules:

<init-param>
  <param-name>SubApplicationSearchPath</param-name>
  <param-value>markupName, mode</param-value>
</init-param>

b.  The second path is the include path, used to include common JSP files in the search. The search will progress from the most qualified to the least qualified, based on the path settings. The search completes when the first file match is found:

<init-param>
  <param-name>IncludesSearchPath</param-name>
  <param-value>locale</param-value>
</init-param>

Portlet Deployment Descriptor: portlet.xml

1.  In order to run our Struts application as a portlet we also need to create a portlet.xml file. Keep in mind that the portlet href attribute defined in portlet.xml must map to the servlet ID in the web.xml file. The definition of the servlets in the web.xml must be in the same order as the definition of portlets in the portlet.xml.

<portlet id="Portlet_1" href="WEB-INF/web.xml#Servlet_1">
    	<portlet-name>Mail</portlet-name>
    ...
  </portlet>

2.  Specify the Struts filter chain inside the portlet.xml by adding the following lines:

<config-param>
<param-name>FilterChain</param-name>
<param-value>StrutsTranscoding</param-value>
</config-param>

The filter chain is used to implement solutions for some of the differences between the versions of WebSphere Portal.

Struts Configuration File: struts-config.xml

1.  The Struts configuration used by Struts portlets references the 1.1 version of the DTD. Change the DOCTYPE if it is of a different version.

<!DOCTYPE struts-config PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"
"http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">

2.  For the Struts Portlet Framework to operate properly, the RequestProcessor must be configured. The RequestProcessor is responsible for the main functionality of processing a request. The default RequestProcessor can be overridden in the struts-config.xml via the controller element. In the struts-config.xml, the following Portal Server RequestProcessor must be specified:

<controller processorClass="com.ibm.wps.portlets.struts.WpsRequestProcessor">
</controller>

Changes to the JSPs
The JSPs for Struts applications in the portal environment have to be modified to adapt to the way the portal server expects portlet URIs to be created.

1.  Remove the following tags from each JSP:

• <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
• <HTML> and </HTML>
• <HEAD> and </HEAD>; Delete all enclosed within these tags, including <META> content, <TITLE> content, and <LINK> content.
• <BODY> and </BODY>

<IMG border="0" src="<%= response.encodeURL("/images/logo.jpg")%>">

or

<script language="JavaScript" type="text/javascript" src="<%=
response.encodeURL("/js/myScript.js")%>"></script>

The the encodeURL() method returns the relative URL of the content, without the hostname and domain information.

Rebuild the Project
After making all these changes, rebuild the project by selecting Project from the Web perspective and choosing the Rebuild All option from the Project menu.

Deploying a Portlet to a WebSphere Portal Test Environment

1. Create a server and server configuration.
2. Add projects to the server.
3. Deploy and test the portlet.

2.  Click Next. The creation wizard appears. Select WebSphere Portal version 5.0 > Test Environment as the Server type.

Note: The procedure for creating a test environment in WebSphere Portal is the same as the one for creating a test environment with WebSphere Studio.

When the wizard has finished, the server and server configuration are shown in the Server Configuration view.

Adding Projects to the Server
The next step is to add the target portlet project to the server.

1. In the Server Configuration view, expand Servers.
2. Right-click on the appropriate server project and select Add.
3. Select the enterprise application project that the portlet project that you want to debug is associated with.

Deploying a Portlet to WebSphere Portal Server

1. Build and export the portal project to create a portlet WAR file by right-clicking the portal project and then selecting Export.
2. Install this WAR file into WebSphere Portal by using Portal Administration functions.
3. Add it to the page container.

Summary