Migrate existing Struts applications

The Jakarta Struts distribution ships an example Struts application that demonstrates the features of Struts, including implementing Struts Actions, creating custom tags, using the Struts tag libraries, authoring JSPs, and form validation. The Struts Portlet Framework demo builds on this example by incorporating WebSphere Portal features, including support for help mode and WML markup. The Struts example required very few changes to enable it for the Struts Portlet Framework.

The file structure of the WAR file for a Struts Portlet Framework is the same as that used for a Struts servlet. The Struts application in the portal server is a WAR file just like it is in the servlet environment. The portlet WAR file has some additional JARS and other requirements, but the basis of the implementation is similar to the servlet application. See WAR file directory structure for more information.

Migrate servlet-based Struts applications

Existing Struts applications can be migrated using the Struts Portlet Framework so the application can be deployed in WebSphere Portal. Since Struts is a framework there are many variations to how the application can be built with Struts. There are also numerous other frameworks that may also be incorporated into the Struts application. The steps in this section can be used as a starting point for the migration effort, but may not cover all of the issues that can be encountered.

Refer to the topic, Update portlets built with the Struts Portlet Framework, to determine what level of Struts the application is using. You might have to follow some additional migration steps that are described in that topic.

Migrate servlet-based Struts applications to the Standard version

Make sure the existing Struts application has been built as a Struts 1.1 application. (See The Struts Application Framework.)
Check Struts Actions to see if the action writes directly to the response object. If it does then, the action must be modified to either return an ActionForward instead, or check to see if the IStrutsPrepareRender interface should be used.
The web deployment descriptor must be updated to use the StrutsPortlet as the portlet class. Remove the servlet-class from the web deployment descriptor, and specify the StrutsPortlet as the portlet class in the portlet deployment descriptor. (See Changes to the Web deployment descriptor.)
The servlet mapping for Struts actions must be specified as the struts-servlet-mapping init parameter. The portlets init parameters are specified in the portlet deployment descriptor.
Create a portlet.xml. The SPFStandardMailReader.war can be used as an example. (See Portlet deployment descriptor.)
Modify the struts-config.xml to specify the WpRequestProcessor as the controller. (See Struts configuration file.)
Modify tags that use pageContext.forward() to use the PortletApiUtils forward. (See Forwards and redirects.) The following example illustrates the change in which the PortletApiUtils object is obtained:
- Old: PortletApiUtils portletUtils = PortletApiUtils.getInstance();
- New: PortletApiUtils portletUtils = PortletApiUtils.getUtilsInstance();
Modify JSPs that use a forward to use the logic forward tag. (See Changes that affect Struts JSPs.)
Modify JSPs as necessary to use the Struts tags for creating URLs, like the Struts Link and Form tags. (See Creating portlet URIs).
The JAR files from the WEB_INF/lib directory of the SPFStandardBlank.war must be used. These files are the Struts JARs and the required Struts Portlet Framework JARs.
The TLD files must be updated from the WEB_INF/lib directory of SPFStandardBlank.war. Verify the taglib attributes and that the JSP correctly reference the TLD files. This has been a common source of problems when migrating existing applications.
The JSPs should be modified so they do not use html, head and body elements. All HTML output to the portal is written in the context of an HTML table cell. (See Portlet Development Best Practices and Coding Guidelines.)