Portal Development Guide

Deploying Portals to Production

Propagation refers to the process of moving the database and LDAP contents of one portal domain environment to another. Oracle provides tools to help with portal propagation. These tools not only move database assets and LDAP information, but they also report differences and potential conflicts between the source and the target environments. You can define policies to automatically resolve conflicts, or an administrator can view a list of differences and decide the appropriate actions to take on a case-by-case basis.

Propagation tools are described in detail in the Production Operations Guide. The Production Operations Guide also helps you through the process of planning a strategy for propagation and provides detailed information on best practices.

This chapter contains information you might find useful as you are propagating (deploying) your portal from the staging environment to the production environment, when it is ready for public access.

The primary tools used in this chapter are the WebLogic Portal propagation tools (to move database and LDAP data between staging, development, and production), WebLogic Server application deployment tools, and any external content or security providers you are using.

Shared J2EE Libraries

The following sections provide more information about J2EE libraries and their behavior during portal deployment. For detailed instructions on how to work with J2EE libraries during deployment, refer to the Production Operations Guide.

Shared J2EE Library References in config.xml

Figure 12-1 highlights the separation between your application code and shared J2EE libraries. The config.xml file resides in the domain, and it specifies the relationships between the web application and the J2EE libraries. Listing 12-1 shows an example <library> element from the config.xml file in a WebLogic Portal domain. As you can see, the library file is an EAR file located in the WebLogic installation area. This library is available to applications deployed on the target server.

<library>
    <name>p13n-app-lib#9.2.0@9.2.0</name>
    <target>AdminServer</target>
    <source-path>D:/bea/weblogic92/common/deployable-libraries/
    p13n-app-lib.ear
    </source-path>
    <deployment-order>1</deployment-order>
    <security-dd-model>DDOnly</security-dd-model>
</library>

When the application is deployed, these relationships provide a plan by which the application and J2EE library code are merged into a single enterprise application.

J2EE libraries can be:

An application can include multiple J2EE libraries, assigning each a deployment order, which determines which version of a given file takes precedence if the same file is contained in multiple libraries. (Files contained in the referencing application always take precedence over library files.) Conceptually, J2EE libraries can be viewed as effectively overlaying (or more precisely, under-laying) the application in which they are included.

J2EE libraries can be employed at either the enterprise or web application level. They use the same file and directory structure as the applications in which they are included—the files contained in a J2EE library are effectively merged into the referencing application at deploy-time.

After deployment, the merged application functions as a standard J2EE application. As a consequence, the deployment information for assets in a library must be merged into the descriptors for the referencing application either prior to (or as part of) the deployment process.

Anatomy of a Shared J2EE Library

A J2EE library is a collection of libraries, resources, and configuration files packaged in an EAR or WAR file. EAR-based J2EE libraries are enterprise application scoped, while WAR-based modules are web application scoped.

Figure 12-2 shows an exploded J2EE library. The J2EE library’s name is p13n-app-lib.

In the META-INF directory is a Manifest.mf file; an example is shown in Listing 12-2. This file includes three elements that define the archive as a J2EE library:

Overriding Shared J2EE Library Settings in the web.xml File

At runtime, the web.xml files in all the shared J2EE libraries are merged, along with the web.xml file in your portal web project. The content of your WEB-INF/web.xml file overrides anything in the shared J2EE libraries, so if you want to change particular settings, you can do it there.

There are many other files for which file contents are merged; these can be overridden in the same way. These files include not only WEB-INF/web.xml but also WEB-INF/weblogic.xml and any files mentioned in weblogic-extension.xml from either the users' application or the shared libraries.

Servlet filters and servlets deployed in the shared libraries' web.xml files can be disabled if desired by deploying the null servlet filter (com.bea.p13n.servlets.NullFilter) or 404 servlet (com.bea.p13n.servlets.SendErrorServlet) in their place. For more information, refer to the Javadoc.

Servlet Mapping Overrides

The web.xml servlet mappings provided by WebLogic Portal reside in J2EE libraries. For example, the showPropertyServlet is defined in

<WLPORTAL_HOME>/content-mgmt/lib/j2ee-modules/content-management-web-lib.war

If you want to add to or modify these servlet mappings, you can add your mappings or provide mapping overrides in your portal web project's file-based web.xml file located in the following path:

PortalWebProject/WebContent/WEB-INF/web.xml

For example, if you want to call the ShowPropertyServlet when /ShowPropertyServlet/* is used in a URL, add the following entry to your file system web.xml file:

<servlet-mapping>

   <servlet-name>ShowPropertyServlet</servlet-name>

   <url-pattern>/ShowBinaryServlet/*</url-pattern>

</servlet-mapping>