Oracle® Fusion Middleware Upgrade Guide for Oracle WebLogic Portal 10g Release 3 (10.3.4) Part Number E14253-02 |
|
|
View PDF |
This appendix describes functional changes in WebLogic Portal 10.3.4 that affect your upgraded environment and might require you to perform manual tasks.
This chapter includes the following sections:
The following sections describe changes that occur when you upgrade directly from WebLogic Portal 8.1 to 10.3.4. You might be required to perform manual tasks.
This section includes these topics:
Section A.1.2, "Upgrading Federated Portals from 8.1 to 10.3.4"
Section A.1.5, "Manually Upgrading Passwords in Content Management Repositories"
Section A.1.8, "Import Wizard Does Not Handle Some Legacy Jar Files"
Section A.1.9, "Changes in Behavior Between Struts 1.1 and 1.2"
Section A.1.13, "Disconnected Desktop Requires desktopStateShared Property"
Section A.1.14, "Correcting Duplicate Portlet Category Names in an Upgraded Application"
Section A.1.15, "Propagation Utility Web Application Obsolete"
The RDBMS Authenticator was supported in 8.1, but was deprecated in Portal 9.2 and all later releases. The RDBMS Authenticator was replaced by the SQL Authenticator.
To enable support in the Upgrade Wizard for upgrading a domain with an RDBMS Authenticator, a manual step is required. Perform the following workaround before you upgrade from an 8.1 RDBMS Authenticator to Portal 10.3.4:
Update your setDomainEnv.cmd/sh variable weblogic.alternateTypesDirectory
to include the path to the deprecated provider: <WLPORTAL_HOME>/p13n/deprecated/lib/security
.
Run the Upgrade Wizard to perform the upgrade. The Upgrade Wizard also removes references to the deprecated RDBMS Authenticator from the domain's config.xml
file.
Tip:
If you did not upgrade your user store during the domain upgrade process, you can perform a manual upgrade later. Run the upgrade_fromdbmsauth_tosqlauth.sql script to upgrade from the WebLogic Portal-specific RDBMS Authenticator to the WebLogic SQL Authenticator. The script is located in the <WLPORTAL_HOME>\p13n\db\<DBMS>\ directory.New features added in WebLogic Portal 10.0 to support federated portal propagation require you to perform the upgrade procedures described in this section.
This section includes the following topics:
WebLogic Portal 10.3.4 supports features of WSRP 2.0 that permit a more flexible and practical approach to propagation of federated portals. With WebLogic Portal 10.3.4, the consumer applications in staging and production environments can point to separate producers. The primary advantage of this new capability is that you can create and modify remote (proxy) portlets in a staging environment in isolation from the production environment.
Before WebLogic Portal 10.0, if you wanted to propagate WSRP consumer applications, the consumers on the source and destination systems had to point to the same producer. This configuration, which is described in detail in the section "WSRP Propagation" in the Production Operations Guide for WebLogic Portal 9.2, included several limitations.
This section explains the upgrade procedure for federated portals. The procedures described here apply to the following scenarios:
It is recommended that you upgrade both your consumer and producer applications to WebLogic Portal 10.0 in your source (staging) and destination (production) environments. Doing so allows you to take advantage of new propagation features and simplifies the propagation process.
Upgrade your consumer applications to WebLogic Portal 10.0. Perform the upgrade in both the source and destination environments.
If you ever performed a bidirectional propagation (propagated from staging to production and then back to staging again) or if propagation fails, you need to follow this sub-step. If neither of these conditions applies to you, skip this sub-step and proceed to Step 2.
Obtain the producer registration handles from each consumer application from both the source and destination systems. To do this, run the List Producers JSP utility as described in Section A.1.2.5, "Listing Producer Handles."
Upgrade your producer application to WebLogic Portal 10.0. Perform the upgrade in both the staging and production environments.
If you ever performed a bidirectional propagation (propagated from staging to production and then back to staging again) or if propagation fails, you need to follow this sub-step. If neither of these conditions applies to you, skip this sub-step and proceed to Step 3.
Update the producer registration handles. To do this, run the Update Registration Handles JSP utility as described in Section A.1.2.6, "Updating Producer Registration Handles."
Propagate the consumer application from the staging to the production environment using the propagation tools. See the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal for information on propagation.
Tip:
When you propagate, you can adjust the scope to include only the Portal Framework resources.This completes the upgrade process. It is now possible for consumer applications in staging and production environments to point to separate producers.
Note:
If you want to retain a configuration where consumers in staging and production point to the same producer, you can do so; however, limitations described in "WSRP Propagation" in the Production Operations Guide for WebLogic Portal 9.2 athttp://download.oracle.com/docs/cd/E13218_01/wlp/docs92/prodOps/index.html
no longer apply.See the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal for detailed information on propagating portals.
If you upgrade your domain and producer application but not the consumers, you need to follow the upgrade procedure described in this section. The procedure described in this section applies equally whether the consumer application(s) are currently at WebLogic Portal 8.1.x or 9.2.
Note:
If you upgrade only the producer, you are required to use the propagation model described in "WSRP Propagation" in the Production Operations Guide for WebLogic Portal 9.2 athttp://download.oracle.com/docs/cd/E13218_01/wlp/docs92/prodOps/index.html
. In this model, consumer applications in both staging and production environments must point to the same producer.Note:
If you upgrade only the producer, you must perform Step 2 and Step 3 below each time you propagate remote portlets in your consumer applications.Upgrade your producer application to WebLogic Portal 10.0.
Obtain the producer registration handles from each consumer application on both the source and destination system. To do this, run the List Producers JSP utility as described in Section A.1.2.5, "Listing Producer Handles."
Update the producer registration handles for each upgraded producer application on the destination system. To do this, run the Update Registrations JSP utility as described in Section A.1.2.6, "Updating Producer Registration Handles."
See the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal for detailed information on propagating portals.
If you upgrade your consumer application(s) but not the producer(s), you need to follow the upgrade procedure described in this section. The procedure described in this section applies equally whether the producer application is currently at WebLogic Portal 8.1.x or 9.2.
Note:
If you want to retain a configuration where consumers in staging and production point to the same producer, you can do so; however, limitations described in "Portal Propagation" in the Production Operations Guide for WebLogic Portal 9.2 athttp://download.oracle.com/docs/cd/E13218_01/wlp/docs92/prodOps/index.html
will no longer apply.Note:
If you upgrade only the consumer(s), you are required to use the propagation model described in "WSRP Propagation" in the Production Operations Guide for WebLogic Portal 9.2 athttp://download.oracle.com/docs/cd/E13218_01/wlp/docs92/prodOps/index.html
. In this model, consumer applications in both staging and production environments must point to the same producer.Note:
If you upgrade only the consumers, steps 2 and 3 are recommended each time you propagate your consumer applications.Upgrade your consumer applications to WebLogic Portal 10.0. Perform the upgrade in both the staging and production environments.
Note:
If you are currently running a configuration where consumer applications in staging and production environments point to the same producer, the following steps are optional but recommended.(Optional/Recommended) Obtain the producer registration handles from each consumer application on both the source and destination system. To do this, run the List Producers JSP utility as described in Section A.1.2.5, "Listing Producer Handles."
(Optional/Recommended) Update the producer registration handles for each upgraded producer application on the destination system. To do this, run the Update Registrations JSP utility as described in Section A.1.2.6, "Updating Producer Registration Handles."
Note:
If you upgrade only the consumers, steps 2 and 3 are recommended each time you propagate your consumer applications.You can run the List Producer JSP utility (listProducers.jsp
) on both the staging and production systems on which your consumer applications are deployed. This utility obtains the registration handles for producers that have been previously added to your consumers.
See the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal for instructions.
You can run the Update Registrations JSP utility (updateRegistrations.jsp
) on both the staging and production systems. This utility updates the registration handles for each consumer application the currently references a given producer.
See the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal for instructions.
When you upgrade a Unified User Profile (UUP) from WebLogic Portal 8.1 to 10.3.4, the p13n_ejb.jar
file is deleted and replaced with a new version of the WebLogic Portal 9.2 file. The new p13n_ejb.jar
file is packaged in the library modules that ship with WebLogic Portal 9.2.
Perform the following steps to upgrade a UUP configured in WebLogic Portal 8.1 to WebLogic Portal 9.2:
Start Oracle Enterprise Pack for Eclipse and create a new Workspace.
Create a new portal domain. Do not create a Portal EAR Project. For instructions on creating a new domain, see the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
Import your Portal 8.1 UUP application into your new environment by choosing File > Import.
In the Import dialog, open the Other folder, select Workshop 8.1 Application, and click Next.
In the Application Import dialog, click Browse and locate your 8.1 UUP application. Select the .work
file and click Open. Verify that the check boxes for the UUP application are selected and click Next, as shown in Figure A-1.
Figure A-1 Locate the 8.1 UUP Application
In the Source Upgrade dialog, click NetUI Project Upgrader options and select the Use WebLogic J2EE Shared Libraries check box. You can also click JSP File Migrator options and select the Replace Oracle NetUI tags with Apache Beehive tags check box (if desired) and click Finish.
After the upgrade finishes, verify that the following actions occurred:
The p13n-ejb.jar
file was removed from the EARContent directory of the UUP application.
The UUP EJB JAR file (for example, UUPExample.jar
) exists in the EARContent directory of the UUP application.
The UUP EJB JAR file is referenced in a module entry in the application.xml
file in the <
UUPApplication>/EARContent/META-INF/
directory.
As an example, the cache entry below was added to the p13n-cache-config.xml
file in the <
UUPApplication>/EARContent/META-INF/
directory:
<p13n:cache> <p13n:name>UUPExampleCache</p13n:name> <p13n:description>Cache for UUP Example</p13n:description> <p13n:time-to-live>60000</p13n:time-to-live> <p13n:max-entries>100</p13n:max-entries> </p13n:cache>
Verify that the User Profile file (for example, UUPExample.usr
) file exists in the data/src/userprofiles/
directory (or where your Datasync folder exists).
Associate your portal application with your WebLogic Server by selecting the server in the Servers tab, right-clicking the server, and choosing Add and Remove Projects. Select the portal application from the Available Projects section, click Add, and then click Finish.
Build and publish your application. Verify the application by starting the WebLogic Server Administration Console and clicking Deployments. Verify that the UUP application is active. Then open the UUP application by expanding the tree and verifying that the UUP JAR file appears as an EJB.
Two JSP tags, <ugm:login>
and <ugm:logout>
, are deprecated in WebLogic Portal 9.2 and 10.0. The <ugm:login>
and <ugm:logout>
JSP tags were moved from the ugm_taglib.jar
file to the auth_taglib.jar
file.
After you upgrade to 10.3.4, you should use the <auth:login>
and <auth:logout>
JSP tags. The attributes and parameters are the same.
After the upgrade is complete, you must manually re-enter the passwords for your third-party repositories using the Administration Console; see the Oracle Fusion Middleware Content Management SPI Development Guide for Oracle WebLogic Portal for more information about editing repository settings.
Until you manually re-enter the passwords for your third-party repositories, you cannot access those repositories.
In WebLogic 8.1 through WebLogic Portal 8.1 SP5, content query expressions were generated differently due to an order of precedence problem. The order of precedence was not maintained when executing a content query expression. For example, the following expression: (a && (b || c), gets evaluated/executed as (a && b || c).
This problem was fixed in Weblogic Portal 10.0 such that the order of precedence is now maintained when executing a content query expression. However, if you want to continue using the WebLogic Portal 8.1 through WebLogic Portal SP5 query behavior, you need to modify your domain scripts to define the following system property: -Dwlp.disable.content.rule.fix=true.
Portal Look & Feels in WebLogic Portal 8.1 used two configuration files for skins and skeletons (in the /skins/<skin_name>
and /skeletons/<skeleton_name>
directories): skin.properties
and skeleton.properties
. Both were text files, and skeleton.properties
was optional.
In WebLogic Portal 10.0, both files are XML, and both are required.
To upgrade a WebLogic Portal 8.1 Look and Feel to the WebLogic Portal 10.3.4 format:
Verify that the portal application that contains the Look and Feel has been converted to WebLogic Portal 10.0, as described in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
Open the Look & Feel in Oracle Enterprise Pack for Eclipse and re-save it. The configuration files are automatically converted to the new XML format.
The cm_taglib.jar
and the pz_compat_taglib.jar
are deleted when you upgrade and Import Wizard flags all JSPs that refer to these taglibs, which have an unsupported taglib URIs. The JSPs will fail.
The cm_taglib.jar
file was not installed by default in a new 8.1 web application, but if you added it to your application for backward compatibility, you must handle this file manually in your upgraded application.
Change all references to the cm_taglib.jar
and the pz_compat_taglib.jar
so that they use supported tags and APIs, and delete the obsolete jar files.
WebLogic Portal support for Struts is slightly different in 10.3.4 if you upgrade to Struts 1.2.
Struts 1.1 support in WebLogic Portal is the same as in previous releases, with the struts-adapter taglibs mapped to URIs using web.xml
. You can use the struts-1.1.war
library module instead of the new struts-1.2.war
library module.
If you are upgrading to Struts 1.2, instead of mapping the struts and struts-adapter taglibs using web.xml
, WebLogic Portal now relies on the JSP 1.2 implicit taglib mapping, wherein any .tld
files in the META-INF
directory in a JAR are implicitly mapped by the web container to the URI specified in the tld. For WebLogic Portal. these are in struts-adapter.jar
, in the path META-INF/tlds
.
Choose to use one of these two methods to upgrade to Struts 1.2:
Modify all JSPs that use the struts taglibs to reference http://bea.com/struts/adapter/tags-html
and http://bea.com/struts/adapter/tags-nested
for the HTML and nested taglibs, and http://struts.apache.org/tags-*
for the remainder of the taglibs that our adapter does not override.
Extract the .tld
s from both struts.jar
(in struts-1.1.war
) and from struts-adapter.jar
(in our portal web library module) and copy them to WEB-INF/tlds
. This allows for the case where you want to continue using the explicit tld mapping via web.xml
.
In WebLogic Portal 8.1, minimized portlet states were persisted only for the session. You can use a workaround, described in the Upgrade Guide for WebLogic Portal 8.1, to set up a backing file that controls the states of portlets under the desktop.
The solution used in 8.1 will continue to work if you depend on this behavior. See the Portlet Development Guide for WebLogic Portal 9.2 at http://download.oracle.com/docs/cd/E13218_01/wlp/docs92/portlets/index.html
for instructions and an example.
Producer and consumer applications developed with WebLogic Portal 10.3.4 are compatible with producers and consumers developed with WebLogic Portal 8.1. That is, a portal developed with WebLogic Portal 10.0 can consume portlets deployed in a WebLogic Portal 8.1 domain. Similarly, portlets exposed in a WebLogic Portal 10.3.4 producer can be consumed by an 8.1 consumer.
However, if you want to use your own key for the 8.1 or 9.2 consumer, you need to follow the procedures outlined the chapter "Establishing WSRP Security with SAML" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.
This section describes changes in how the encoding is set on the HTTP response.
In WebLogic Portal 8.1, the following methods were used to set the encoding:
Examine the .portal
file for a directive.page
element. If that element is present, obtain the encoding from an attribute there.
If the element is not present, use the JSP encoding configuration, which looks at the <encoding>
element in the <jsp-param>
section of the web.xml
file; the default is ISO-8859-1 if these elements are missing.
Both of these mechanisms are now deprecated.
See "Working with Encoding in HTTP Responses" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal for instructions on setting encoding and editing encoding in the IDE.
For compatibility with 8.1 and prior releases, and to support the few desirable uses of a disconnected desktop, WebLogic Portal 10.3.4 provides a new, but deprecated, boolean property called desktopStateShared
for the StandalonePortletURL
and the associated JSP tag. You can use this property to retain the previous "disconnected desktop" behavior. The default value of this property and attribute will be true
, causing the portlet to be connected to a desktop.
Explicitly setting either the path
or contextualPath
properties on the URL or tag also disassociates the resulting standalone portlet from its originating desktop. This also holds true for any URLs generated within the context of the standalone portlet—setting path
or contextualPath
causes the resulting URLs to become disassociated with the originating desktop.
In 8.1 and previous releases of WebLogic Portal it was possible, though not recommended, to create more than one portlet category with the same name, at the same level in the hierarchy. In 10.3.4, this operation is not permitted. (You can use the same name for more than one category, but they must not be "peers" in the hierarchy.)
When you upgrade a portal application to 10.3.4, any duplicate portlet category names that were used previously are preserved. It is extremely important that you edit these category names to be unique; otherwise the WebLogic Portal propagation tools might cause unexpected results, or errors might occur during the propagation process.
The Propagation Utility web application, propagation.war
, became obsolete as of WebLogic Portal 9.2. This application was introduced in a patch for WebLogic Portal 8.1 SP4 and later incorporated into WebLogic Portal 8.1 SP5. If you are upgrading a WebLogic Portal web application in which you previously installed the file propagation.war
into the root directory of any WebLogic Portal enterprise applications, it is recommended that you remove the file before or after upgrading to WebLogic Portal 10.3.4.
In WebLogic Portal 8.1, the capability to edit definition labels existed, but was not recommended. Modifying the definition label could have unintended implications; for example, exposing a protected resource or breaking WSRP (which uses the definition label as the portlet handle).
As of WebLogic Portal 9.2, this functionality has been replaced by a much richer ability to move portal resources (books, pages, desktops) between production and development environments, without losing user customizations or changing labels. These new features include XIP and the propagation utility. XIP allows you to target individual portal resources to import and export between development and production systems, and you can specify the scope (library, admin, or visitor). For more information about WebLogic Portal's propagation tools, see the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal.
WebLogic Portal inventories saved with WebLogic Portal 8.1 or 9.2 cannot be used with WebLogic Portal 10.0 propagation tools.
The following sections describe changes that occur when you upgrade from WebLogic Portal 9.2 or 9.2 MP1 to 10.2/10.3/10.3.2/10.3.4. You might be required to perform manual tasks.
This section includes the following topics:
The procedure for upgrading federated portals from 9.2 to 10.3.4 is identical to the procedure for updating from 8.1 to 10.3.4. See Section A.1.2, "Upgrading Federated Portals from 8.1 to 10.3.4" for detailed instructions.
Your WebLogic Portal 9.2 or 9.2 MP1 UUP automatically works in WebLogic Portal 10.3.4. You do not need to upgrade your 9.2 UUP.
For backward compatibility to WebLogic Portal 8.1 and previous releases, and to support the few desirable uses of a disconnected desktop, WebLogic Portal 9.2 provided a new, but deprecated, boolean property called desktopStateShared
for the StandalonePortletURL
and the associated JSP tag. This property is retained in 10.3.4 and is still deprecated.
For more details, see Section A.1.13, "Disconnected Desktop Requires desktopStateShared Property."
After completing the above sections, you must re-index your WLP content. For detailed instructions on re-indexing WLP content, see the Oracle Fusion Middleware Autonomy Search Integration Sample Guide for Oracle WebLogic Portal.
Producer and consumer applications developed with WebLogic Portal 10.3.4 are compatible with producers and consumers developed with WebLogic Portal 9.2. That is, a portal developed with WebLogic Portal 10.3.4 can consume portlets deployed in a WebLogic Portal 9.2 domain. Similarly, portlets exposed in a WebLogic Portal 10.3.4 producer can be consumed by a 9.2 consumer.
However, if you want to use your own key for the 9.2, 10.0, 10.2, 10.3, 10.3.2, or 10.3.4 consumer, you need to follow the procedures outlined the chapter "Establishing WSRP Security with SAML" in the Oracle Fusion Middleware Content Management SPI Development Guide for Oracle WebLogic Portal.
If you created any propagation Ant scripts in 9.2, you must either manually update them or regenerate the scripts in 10.0. This change is required because several JAR file names have changed and the package name for all propagation Ant tasks has changed.
If you regenerate your scripts using Oracle Enterprise Pack for Eclipse, the correct filenames and package name will be used automatically. If you must update your scripts manually (for instance, if you created them manually in the first place), you need to make the following changes:
The propagation ant tasks are now located in the package com.bea.propagation.ant.taskdefs
.
The following table lists the 9.2 JAR file names and the updated names for 10.0:
WebLogic Portal inventories saved with WebLogic Portal 8.1 or 9.2 cannot be used with WebLogic Portal 10.3.4 propagation tools.
WebLogic Server provides the option of using an external RDBMS as a datastore that is used by authorization, role mapping, credential mapping, and certificate registry providers. WebLogic Portal uses this datastore as part of its default domain configuration. When you configure a WLP domain, the RDBMS security store tables are automatically created.
For detailed information on the RDBMS security store, see the WebLogic Server document, "Managing the RDBMS Security Store," in Oracle Fusion Middleware Securing Oracle WebLogic Server. See also "RDBMS Security Store Tables" in the Oracle Fusion Middleware Database Administration Guide for Oracle WebLogic Portal.