Integrating Struts Applications

You can integrate, or import, a Struts 1.1 application into an enterprise application in WebLogic Workshop. Once in WebLogic Workshop, you can quickly and easily give the Struts application a portal user interface, add personalization and campaign functionality to it, and take advantage of WebLogic Portal's content and user management services.

This topic contains the following sections:

Integrating a Struts Application into a Portal

Best Practices and Development Issues

Struts and Page Flows

Integrating a Struts Application into a Portal

Create a portal application and portal Web project in which to add the Struts application. See Creating a Portal Application and Portal Web Project. Struts support is added automatically.
In order for URLs to resolve correctly, Java Page Flow support must be enabled in the portal Web project's WEB-INF/netuix-config.xml file, as shown in the following example. Notice the <enable> element is set to true.
```

<pageflow>
    <enable>true</enable>
</pageflow>
```
If this block is not present in netuix-config.xml, do not add it. Without the block, the setting defaults to true.
Add the Struts application to the portal Web project.
1. Copy any JSP, HTML, or image files into the portal Web project following the standard Struts module directory structure (the module path is the directory path relative to the Web application root).
2. Copy any supporting Java source used by the Struts application into the project's WEB-INF/src.
3. Copy any necessary custom JARs for the Struts application into WEB-INF/lib.
4. Copy the Struts application's struts-config.xml or module configuration file into WEB-INF, but rename it struts-auto-config-<module-path>.xml, where <module-path> is the module path to the Struts application relative to the Web application root, with all instances of '/' or '\' changed to '-'.
  
  For example, if the module path is /struts/my/module, struts-config.xml should be renamed to struts-auto-config-struts-my-module.xml. Naming the module configuration file in this manner enables the PageFlowctionServlet used as the Action Servlet to automatically register the module without explicitly registering it with an init-param in web.xml. If you don't want to take advantage of this functionality, you can rename struts-config.xml arbitrarily, but you must manually register the module in web.xml as usual for a Struts 1.1 module.
5. In the module configuration file, add the following line to configure the RequestProcessor that is required for portal integration:
  
  <controller processorClass="com.bea.struts.adapter.action.AdapterRequestProcessor"/>
  
  (unless the Struts application requires a custom RequestProcessor).
Create a portlet that contains a StrutsContent control that specifies the module and the default action for the Struts application. See Building Portlets.
Add the new portlet to the portal using the WebLogic Workshop Portal Designer. See Adding a Portlet to a Portal.

Best Practices and Development Issues

Use the following guidelines for integrating Struts applications in portals:

It is highly recommended that you fully develop and test a Struts application before attempting to host it within a portal. This will help to separate the complexities of simply developing a working Struts application from the additional issues involved in putting the Struts application into a portlet.
Any Struts applications that are intended for use in a Portal must be developed as Struts modules, including the usage of the html:link tag for any URLs used in JSPs. Without this, it is impossible for the portal framework to perform the necessary URL rewriting that is required to transparently modify links when the Struts application is used within a portlet.
If you encounter stack traces or messages in the Struts application portlet showing that an action cannot be found, ensure that the module is correctly configured, named correctly, and registered in web.xml. This can be tested by running the Struts application stand-alone
If you encounter resource not found exceptions or class not found exceptions for dependent classes:
- Make sure that all dependent Java source exists in WEB-INF/src, and that it has successfully been built into the corresponding class files in WEB-INF/classes.
- If more than one message-resource element is specified in the Struts configuration file for the module, any module files that reference a non-default message bundle must append the module path to the bundle key. For example, if the bundle key is alternate, and the module is /my/module, any users of the bundle will have to fully qualify it as alternate/my/module.
If following action links in a Struts portlet results in full-screen, stand-alone Struts pages, make sure that struts-adapter JSP tag libraries are in the project's WEB-INF/lib directory and that they are registered in web.xml.
If the"No ActionResult returned for action" error is returned when the action attribute of an html:form element contains a query parameter, use a hidden html:text input field.
Some Struts applications use of a custom RequestProcessor. Portal Struts integration support requires that certain behaviors of a RequestProcessor be overridden. The class com.bea.struts.adapter.action.AdapterRequestProcessor, located in struts-adapter.jar, provides this standard behavior and must be used in all Struts applications used within a portal. Any custom RequestProcessors must either extend this class or use a utility class to perform the same required operation that this RequestProcessor performs. When extending this class, overrides of doForward() must call the superclass doForward() and also must not attempt to write to the response. Custom RequestProcessors that do not extend AdapterRequestProcessor must call com.bea.struts.adapter.action.AdapterRequestProcessorUtil.forwardUsingRequest() to perform any forwarding operations. (This method replaces an actual RequestDispatcher forward request with an operation that simply captures the forward URI for later use in including the URI into the portal output.)
If a Struts application depends on the use of a custom Action servlet, it must be refactored to use a custom RequestProcessor instead, as outlined above, and as recommended by the Struts 1.1 implementation. Since the Page Flow functionality in WebLogic Portal uses a custom Action servlet, and since there can be only one Action servlet in a portal Web project, portal Struts integration requires that the Action servlet not be customized. For more information on refactoring an Action servlet customization into a RequestProcessor customization, see the Struts 1.1 documentation at http://jakarta.apache.org/struts/.
Module switching - The StrutsContent control supports module switching using Action forwards, as described in the Struts documentation found on http://jakarta.apache.org/struts/. If the Action forward returned by an invoked Action results in a content URI that resides in another module, the current module will be switched to the corresponding new module, and all further requests to the Struts portlet containing the control will be performed using the new module. Module switching should only be done using Action forwards, not by using the <html:link> tag to directly link to a JSP in another module; doing so may prevent the portal and Struts frameworks from correctly setting up and selecting the module.
If a Struts application used within a Portal also needs to support stand-alone operation, JSPs referenced by Action forwards must be authored to use several optional tags in the HTML tag library found in struts.jar and struts-adapter.jar. The first of these, <html:html>, is found in both Struts and the Struts-adapter. The Struts-adapter version overrides the Struts version of the tag and adds support for detecting whether or not to inhibit rendering of the tag output text if it is used from within a portal, where outputting the HTML text would result in non-well-formed HTML. Two additional tags are provided in the Struts-adapter version of the HTML tag library, and should be used in JSPs that also need to be used stand-alone: <html:head> and <html:body>. These two tags have the same portal-aware rendering behavior as the <html:html> tag.

Struts and Page Flows

WebLogic Workshop provides interchangeable support for Struts modules and Page Flow controller classes working together in the same Web project. See Interoperating With Struts and Page Flows.