Struts Portlet in Weblogic Portal Server
Table 4-5 describes each WebLogic Portal-specific field of the dialog.
The value automatically displayed in this dropdown menu corresponds to the selections made in the tree view of project facets. You can select a preset group of facets from the dropdown menu, or select and unselect specific check boxes in the tree display. If you select a customized set of facets, displays in the field.
§ Collaboration Portlets – causes the J2EE library wlp-collab-portlets-app-lib to be associated with your project. You can use these portlets outside a GroupSpace environment.
For detailed instructions on creating a GroupSpace-based application, refer to the Communities Guide
Note: Do not add GroupSpace to portal web projects that already contain non-GroupSpace portals. For more information, refer to the Communities Guide.
The New Portal Web Project – Web Module dialog is shown in Figure 4-5.
Table 4-6 describes each field of the dialog.
The New Portal Web Project – WebLogic Web Module dialog is shown in Figure 4-7.
Table 4-7 describes the dialog.
If you select the Use Shared J2EE Libraries radio button, Weblogic Portal creates associations with shared J2EE libraries rather than copying the complete set of JAR files into your project. BEA recommends that you use shared J2EE libraries because of their significant advantages in source control, file sharing, and patch application. With any future patch installations, Weblogic Portal supports only configurations that do not have copied J2EE library resources in the project. For more information about shared J2EE libraries, refer to Weblogic Portal and Shared J2EE Libraries.
Once You have created the Portal EAR project & Portal WEB project You can integrate the struts application with the portal.
Integrating Struts Applications
You can integrate, or import, a Struts application into an enterprise application in Workshop for WebLogic. Once in Workshop for WebLogic, you can give the Struts application a portal user interface by creating portlets, add personalization and campaign functionality, and take advantage of WebLogic Portal’s content and user management services.
If you have a top-level Struts application, you must refactor it before you can integrate it. 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 WebLogic Portal to perform the necessary URL rewriting that is required to transparently modify links when the Struts application is used within a portlet.
§ To use Struts 1.2, which is the default version of Struts used for new portal web projects, BEA recommends that you change your JSPs to use WebLogic Portal taglib URIs; this prevents you from having to change your
web.xml file, and provides the benefit that these taglibs are automatically deployed.
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-adapter.jar (a file that is created by BEA). 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; use them in JSPs that also need to be used standalone:
<html:body>. These two tags have the same portal-aware rendering behavior as the
Some Struts applications use a custom RequestProcessor. WebLogic Portal Struts integration requires that you override certain behaviors of a RequestProcessor. 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 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 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 documentation at
The StrutsContent control supports module switching using Action forwards. If the Action forward returned by an invoked Action results in a content URI that resides in another module, the current module is switched to the corresponding new module, and all further requests to the Struts portlet containing the control are performed using the new module. Perform module switching using only Action forwards, not by using the tag to directly link to a JSP in another module; doing so might prevent the portal and Struts frameworks from correctly setting up and selecting the module.
Once you create the Portal EAR project and Portal WEB project then the directory structure will be like…
Now we are ready to integrate the struts application into weblogic portal 10.
We need to do all the modifications in “src” and “Webcontent” folders exists in the WAR folder.
Copy all the java files into “src” folder. With packaging structure. If class files resides in classes->struts->example foder in normal struts application then in case of struts portlet copy the “.java” files into “src” folder with package “struts->example”.
No need to copy the struts.jar and struts-adapter.jar into WEB-INF->lib because when you create struts portlet those files are automatically included in the project in “Merged Project Content”. Except this files copy all jar files in WEB-INF->lib.
Copy the Struts application module’s
struts-config.xml or module configuration file into
WEB-INF, but rename it
<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, then rename
struts-auto-config-struts-my-module.xml. Naming the module configuration file in this manner enables the
PageFlowActionServlet used as the Action Servlet to automatically register the module without explicitly registering it with an
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 or 1.2 (Beehive) module.
In the module configuration file, add the following line to configure the RequestProcessor that is required for portal integration:
(unless the Struts application requires a custom RequestProcessor). (This AdapterRequestProcessor class resides in the struts-adapter.jar which is included in the portal application by weblogic itself automatically so no need to include it explicitly.)
copy all the jsp files in the struts module directory(Which you will create yourself or if you hae name the struts-config.xml file as struts-auto-config-strutsApp.xml then at the time of portlet creation the portlet by right clicking on struts-auto-config-strutsApp.xml file and select “Generate Portlet” , strutsApp folder will be created in the WebContent directory and the portlet which has been generated will be placed in that folder). In the same foder structure you have used in the normal struts application. And give the path of those jsp files into struts-auto-config-strutsApp.xml accordingly.
Use the Portlet Wizard to generate a portlet based on a Struts module, as explained in this section.
2. Select Generate Portlet from the menu. The wizard automatically collects and displays the module path and configuration file name(s) in the Struts Config File dialog. An example is shown in Figure 5-17. Use the Browse and Add buttons to locate and add additional configuration files, if applicable.
1. Click Next.
1. Click Create.
The Workshop for WebLogic window updates, adding the Portlet_Name
.portlet file to the display tree; by default, Workshop for WebLogic places the portlet file in the directory that you specified in the Struts Module Path dialog of the wizard.
File->new->Portal and then save it.
Now Click on the portlet file in package explorer and drag into the portal window and save it.
Now select the .portal file and then right click on it and select Run on Server from Run menu.
Best Practices and Development Issues
Use the following guidelines for integrating Struts applications in portals: