| Oracle® Fusion Middleware Portal Development Guide for Oracle WebLogic Portal 10g Release 3 (10.3.2) Part Number E14243-02 |
|
|
View PDF |
| Oracle® Fusion Middleware Portal Development Guide for Oracle WebLogic Portal 10g Release 3 (10.3.2) Part Number E14243-02 |
|
|
View PDF |
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 Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal. 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.
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 Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal.
Figure 16-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. Example 16-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.
Example 16-1 J2EE Library Referenced in config.xml File
<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.
Figure 16-1 Application Referencing a Shared J2EE Library
Tip:
You can create a deployment plan to configure what gets mapped at runtime when the files merge. Deployment plans are described in the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal.J2EE libraries can be:
Included by reference
Perhaps the most important thing to know about shared J2EE libraries is that they are included in your application by reference. Within your WebLogic Portal application is a configuration file that references all of the J2EE libraries that your application requires. When you deploy your application, the library files are automatically located and included with your application.
Independently versioned
Another important thing to know about J2EE libraries is that they are independently versioned. This means that each J2EE library includes within it a descriptor file that lists the module's version number. At deploy time, these descriptors are located, read, and merged automatically, ensuring that your application retrieves the correct version of each J2EE library that it requires.
Shared across multiple applications
A set of shared J2EE libraries is installed when you create a WebLogic Portal domain. This set of J2EE libraries is used by all applications running in that domain.
Separately deployed
Because J2EE libraries are separately deployed, applications can be upgraded easily by replacing a single J2EE library.
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.
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 16-2 shows an exploded J2EE library. The J2EE library's name is p13n-app-lib.
Figure 16-2 Example of an Exploded Shared J2EE Library
In the META-INF directory is a Manifest.mf file; an example is shown in Example 16-2. This file includes three elements that define the archive as a J2EE library:
Extension-name – Specifies the name of the J2EE library.
Specification-Version – Specifies the initial version of the J2EE library.
Implementation-Version – (optional) Specifies the current version of the J2EE library. You increment this version number each time the J2EE library is updated. When an application is deployed, deployment descriptors specify which J2EE libraries to deploy. This version number can be referenced in deployment descriptors so that the intended version of the module is included.
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 Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal.
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>
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|