Skip Headers
Oracle® Fusion Middleware Upgrade Guide for Oracle WebLogic Portal
10g Release 3 (10.3.2)

Part Number E14253-01
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

A Functional Changes Affecting Your WebLogic Portal Environment

This appendix describes functional changes in WebLogic Portal 10.3.2 that affect your upgraded environment and might require you to perform manual tasks.

This chapter includes the following sections:

A.1 Functional Changes from Portal 8.1 to 10.3.2

The following sections describe changes that occur when you upgrade directly from WebLogic Portal 8.1 to 10.3.2. You might be required to perform manual tasks.

This section includes these topics:

A.1.1 Upgrading to the SQL Authenticator

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.2:

  1. Update your setDomainEnv.cmd/sh variable weblogic.alternateTypesDirectory to include the path to the deprecated provider: <WLPORTAL_HOME>/p13n/deprecated/lib/security.

  2. 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.

A.1.2 Upgrading Federated Portals from 8.1 to 10.3.2

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:

A.1.2.1 Overview

WebLogic Portal 10.3.2 supports features of WSRP 2.0 that permit a more flexible and practical approach to propagation of federated portals. With WebLogic Portal 10.3.2, 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:

A.1.2.2 Upgrading Producer and Consumer Applications

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.

  1. 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."

  2. 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."

  3. 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 at http://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.

A.1.2.3 Upgrading Only the Producer Applications

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 at http://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.
  1. Upgrade your producer application to WebLogic Portal 10.0.

  2. 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."

  3. 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.

A.1.2.4 Upgrading Only the Consumer Applications

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 at http://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 at http://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.
  1. 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.
  2. (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."

  3. (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.

A.1.2.5 Listing Producer Handles

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.

A.1.2.6 Updating Producer Registration Handles

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.

A.1.3 Upgrading UUPs

When you upgrade a Unified User Profile (UUP) from WebLogic Portal 8.1 to 10.3.2, 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:

  1. Start Oracle Enterprise Pack for Eclipse and create a new Workspace.

  2. 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.

  3. Import your Portal 8.1 UUP application into your new environment by choosing File > Import.

  4. In the Import dialog, open the Other folder, select Workshop 8.1 Application, and click Next.

  5. 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

    Description of Figure A-1 follows
    Description of "Figure A-1 Locate the 8.1 UUP Application"

  6. 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.

  7. 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).

  8. 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.

  9. 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.

A.1.4 Understanding JSP Tag Changes

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.2, you should use the <auth:login> and <auth:logout> JSP tags. The attributes and parameters are the same.

A.1.5 Manually Upgrading Passwords in Content Management Repositories

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.

A.1.6 Maintaining Content Queries

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.

A.1.7 Upgrading Look & Feels

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.2 format:

  1. 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.

  2. 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.

A.1.8 Import Wizard Does Not Handle Some Legacy Jar Files

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.

A.1.9 Changes in Behavior Between Struts 1.1 and 1.2

WebLogic Portal support for Struts is slightly different in 10.3.2 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 .tlds 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.

A.1.10 Portlet State Persistence

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.

A.1.11 WSRP Security Compatibility

Producer and consumer applications developed with WebLogic Portal 10.3.2 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.2 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.

A.1.12 Working with Encoding in HTTP Responses

This section describes changes in how the encoding is set on the HTTP response.

A.1.12.1 Setting Encoding for 8.1

In WebLogic Portal 8.1, the following methods were used to set the encoding:

  1. Examine the .portal file for a directive.page element. If that element is present, obtain the encoding from an attribute there.

  2. 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.

A.1.12.2 Setting Encoding for 10.3.2

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.

A.1.13 Disconnected Desktop Requires desktopStateShared Property

For compatibility with 8.1 and prior releases, and to support the few desirable uses of a disconnected desktop, WebLogic Portal 10.3.2 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.

A.1.14 Correcting Duplicate Portlet Category Names in an Upgraded Application

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.2, 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.2, 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.

A.1.15 Propagation Utility Web Application Obsolete

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.2.

A.1.16 Definition Labels Not Editable in 10.3.2

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.

A.1.17 Propagation Inventory Compatibility

WebLogic Portal inventories saved with WebLogic Portal 8.1 or 9.2 cannot be used with WebLogic Portal 10.0 propagation tools.

A.2 Functional Changes from Portal 9.2 to 10.2/10.3/10.3.2

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. You might be required to perform manual tasks.

This section includes the following topics:

A.2.1 Upgrading Federated Portals

The procedure for upgrading federated portals from 9.2 to 10.3.2 is identical to the procedure for updating from 8.1 to 10.3.2. See Section A.1.2, "Upgrading Federated Portals from 8.1 to 10.3.2" for detailed instructions.

A.2.2 Upgrading UUPs

Your WebLogic Portal 9.2 or 9.2 MP1 UUP automatically works in WebLogic Portal 10.3.2. You do not need to upgrade your 9.2 UUP.

A.2.3 Disconnected Desktop Requires desktopStateShared Property

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.2 and is still deprecated.

For more details, see Section A.1.13, "Disconnected Desktop Requires desktopStateShared Property."

A.2.4 Re-Index WLP Content

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.

A.2.5 WSRP Security Compatibility

Producer and consumer applications developed with WebLogic Portal 10.3.2 are compatible with producers and consumers developed with WebLogic Portal 9.2. That is, a portal developed with WebLogic Portal 10.3.2 can consume portlets deployed in a WebLogic Portal 9.2 domain. Similarly, portlets exposed in a WebLogic Portal 10.3.2 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, or 10.3.2 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.

A.2.6 Upgrading Propagation Scripts

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:

Table A-1 Mapping of 9.2 JAR Names to 10.0 JAR Names

9.2 JAR Name 10.0 JAR Name

p13n_prop.jar

propagation.jar

p13n_prop_online.jar

propagation_online.jar

p13n_prop_ant.jar

propagation_ant.jar


A.2.7 Propagation Inventory Compatibility

WebLogic Portal inventories saved with WebLogic Portal 8.1 or 9.2 cannot be used with WebLogic Portal 10.3.2 propagation tools.

A.2.8 RDBMS Security Store

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.