|
|
You can use the instructions presented in this chapter to add WebLogic Portal functionality to existing applications. For example, you can:
You can easily transform an existing Workshop for WebLogic web application into a Portal web project by installing the necessary WebLogic Portal– specific facets into it. Then you can give the web application a portal user interface, add personalization and campaign functionality, and take advantage of WebLogic Portal's content and user management services.
You might originally have selected not to install Commerce Taglibs in your portal project; you can add that feature later if desired.
| Note: | Do not add GroupSpace to portal web projects that already contain non-GroupSpace portals. For more information, refer to the Communities Guide. |
Regardless of how the application is surfaced, it will maintain the full functionality intended in its design.
This chapter contains the following sections:
Integrating a web application into a WebLogic Portal environment involves the following steps:
| Note: | These instructions assume that you have an existing web application that conforms to the requirements of the Workshop for WebLogic environment, and includes an EAR Project and a Workshop for WebLogic Web Project. |
To integrate an existing web application into Workshop for WebLogic and add WebLogic Portal functionality, follow these steps:
The project facets associated with this EAR project display in the table, as shown in Figure 5-1.
The Add/Remove Project Facets - Select Project Facets dialog displays.
All the features for the WebLogic Portal facet are selected by default; the example in Figure 5-2 shows the expanded tree with the WebLogic Portal facet selected.
The Project Facets table in the properties dialog displays the facets that you just added, as shown in Figure 5-3.
The Package Explorer view includes the new portal-related content.
When you are finished, the display in the Properties view includes the WebLogic Portal facets, and the tree in the Package Explorer view shows the added portal-specific shared J2EE libraries.
Figure 5-4 shows an example of the new portal-related content that is added for the EAR project and web project.
You can now use WebLogic Portal features to create, assemble, and manage a portal environment.
| Note: | Do not add GroupSpace to portal web projects that already contain non-GroupSpace portals. For more information, refer to the Communities Guide. |
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.
This topic contains the following sections:
Follow the guidelines presented in this section as you prepare your existing Struts application for integration with WebLogic Portal:
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.
As part of this process, modify your application to use WebLogic Portal tags using either of these methods:
web.xml to map the WebLogic Portal struts adapter tags to the URI that you already have in your JSPs; this allows you to use your existing JSPs. 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.jar and struts-adapter.jar (a file that is created by Oracle). 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:head> and <html:body>. These two tags have the same portal-aware rendering behavior as the <html:html> tag.
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 http://jakarta.apache.org/struts/.
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 <html:link> 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.
Perform these steps to integrate your refactored Struts application:
WEB-INF/netuix-config.xml file to enable it. Listing 5-1 shows the syntax of the tag that you might need to add to the netuix-config.xml file. Notice that the <enable> element is set to true.<!-- Enable or disable Pageflow support -->
<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.
| Note: | The following steps assume a deployment structure that is not based on split-source; your specific steps might differ from these example steps. |
/src.WEB-INF/lib folder.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, then rename struts-config.xml to 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 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 or 1.2 (Beehive) module.
<controller processorClass="com.bea.struts.adapter.action .AdapterRequestProcessor"/>
(unless the Struts application requires a custom RequestProcessor).
Use the following guidelines for integrating Struts applications in portals:
web.xml. This can be tested by running the Struts application stand-alone.
Generally the integration process for JSF is simple, requiring only that you follow the instructions accompanying the distribution of JSF that you are using. The portal-specific tasks for incorporating a JSF application into WebLogic Portal are:
.portlet file with a facesContent control.This step is optional but Oracle highly recommends it. For more information about this tag, refer to JSF and the namingContainer JSP Tag.
The following section contains more information about the namingContainer JSP tag.
The purpose of the namingContainer JSP tag is to ensure generation of unique IDs on a page. Currently the JSF architecture does not provide an explicit hooking mechanism to override default component ID generation. JSF uses a hierarchical namespace for components on a page, and JSF automatically generates unique IDs for the components on a page; however, because JSF is not “aware” of the portal, it might generate non-unique component IDs on a page. For simple forms you would not likely experience this problem, but if you use JavaScript on a page and non-unique IDs are generated, the Javascript might target the wrong component.
For more detail on the implementation of JSF in WebLogic Portal, refer to the Javadoc for the package com.bea.portlet.adapter.faces.
If you have an existing non-portal application with page flows, you can integrate those page flows into a portal by installing the WebLogic Portal-related facets using the steps described in Integrating an Existing Web Application into Workshop for WebLogic; then you surface those page flows using portlets. You can also build new page flows within the portal web project before creating page flow portlets.
For instructions on creating a page flow, refer to the documentation for Workshop for WebLogic. For instructions on creating page flow portlets, refer to the “Building Portlets” chapter in the Portlet Development Guide.
In order for URLs in the page flows to resolve correctly, page flow support must be enabled. By default, page flow support is enabled, but if the page flow setting has been disabled at some point, you must edit the portal web project's WEB-INF/netuix-config.xml file to enable it. Listing 5-2 shows the syntax of the tag that you might need to add to the netuix-config.xml file. Notice that the <enable> element is set to true.
<!-- Enable or disable Page Flow support -->
<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.
You can add a project facet to your EAR project or portal web project at any time. For example, in your portal web project you might originally have selected not to install the facet that enables visitor tools, but you might decide later that you want to use this feature.
| Note: | Do not add GroupSpace facets to portal web projects that already contain non-GroupSpace portals. For more information, refer to the Communities Guide. |
To add a facet to an existing EAR project or portal web project, follow these steps:
The Properties dialog displays; an example is shown in Figure 5-5.
The Add/Remove Project Facets dialog displays.
Figure 5-6 shows an example for a typical portal web project with Collaboration Portlets selected for addition.
The facets are added and then displayed in the list of facets in the Properties dialog.
A recommended method of integrating a web application’s functionality into a portal is to incorporate the application into Java page flow portlets, but this implementation could be difficult if the application is not based on the MVC architecture, Java, or Struts. In these cases you can continue to host the application externally from the portal project but surface its content within WebLogic Portal.
The alternative implementations generally rely on a JSP portlet acting as a sort of proxy, which allows the existing web application to remain intact. Some possible implementations for JSP “proxy” portlets include:
Web Services for Remote Portlets (WSRP) provides another alternative implementation, but this implementation requires the legacy server to support SOAP and WSDL, and works best with existing applications designed using MVC.
WebLogic Portal supplies a utility JSP tag called uriContent that you can use to retrieve an HTTP response document from a given URI. The browser portlet uses the uriContent tag (Content URL) to surface an external web application in a portal, using a portlet. For more information about the browser portlet, refer to the Portlet Development Guide.
|
