|
|
This appendix describes functional changes in WebLogic Portal 10.3 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. You might be required to perform manual tasks.
This section includes these topics:
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:
weblogic.alternateTypesDirectory to include the path to the deprecated provider: <WLPORTAL_HOME>/p13n/deprecated/lib/security. 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 supports features of WSRP 2.0 that permit a more flexible and practical approach to propagation of federated portals. With WebLogic Portal 10.3, 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 “WSRP Propagation” in the WebLogic Portal 9.2 Production Operations Guide, 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.
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 Listing Producer Handles.
Update the producer registration handles. To do this, run the Update Registration Handles JSP utility as described in Updating Producer Registration Handles.
| 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 Portal 9.2 Production Operations Guide no longer apply. |
See the Production Operations Guide 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 Portal 9.2 Production Operations Guide. 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. |
See the Production Operations Guide 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 WSRP Propagation in the WebLogic Portal 9.2 Production Operations Guide 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 WebLogic Portal 9.2 Production Operations Guide. 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. |
| 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. |
| 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 Production Operations Guide 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 Production Operations Guide for instructions.
When you upgrade a Unified User Profile (UUP) from WebLogic Portal 8.1 to 10.3, 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:
.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.
p13n-ejb.jar file was removed from the EARContent directory of the UUP application.UUPExample.jar) exists in the EARContent directory of the UUP application.application.xml file in the <UUPApplication>/EARContent/META-INF/ directory.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>UUPExample.usr) file exists in the data/src/userprofiles/ directory (or where your Datasync folder exists).
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, you should use the <auth:login> and <auth:logout> JSP tags. The attributes and parameters are the same.
If you are upgrading from WebLogic Portal 8.1 and used Autonomy search, you need to do the following to upgrade to the new version of Autonomy that is included with WebLogic Portal 10.3. The upgrade process does not automatically migrate your existing search settings and databases to the new search capabilities. You need to manually configure Autonomy search to work with your upgraded applications.
The new version of Autonomy is installed into the <WLPORTAL_HOME>/content-mgmt/thirdparty/autonomy-wlp10 directory. For more information about configuring Autonomy search, see the
Integrating Search Guide.
After installing and configuring Autonomy search, do the following to upgrade your application to use the new features:
If you wrote applications using the WebLogic Portal com.bea.query classes or using the 8.1 Autonomy API and want to continue using these applications without using the new 9.2 version of the Autonomy API, you need to manually add the older, deprecated APIs to your application.
However, if you continue to use the 8.1 API (either WebLogic Portal or Autonomy’s), those APIs will take priority over the 10.0 API and are NOT compatible with the 10.0 Autonomy engine. This means that some 10.0 content management features will not work, such as full-text search.
If you want to continue to use the 8.1 version of Autonomy with your portal application, you must manually add the older APIs to your installation.
To add the older Autonomy version to your 10.0 application:
autonomyCompat.jar and autonomyClient.1.5.0.jar from <WLPORTAL_HOME>/info-mgmt/lib/thirdparty/search/81-compat-only into the application_home/APP-INF/lib directory.The 8.1 Autonomy APIs and engines are now running.
If you want to upgrade to use the 10.0 version of Autonomy, after you have completed the steps in Using 8.1 Search within a 10.0 Portal Application, you can reverse the implementation.
To upgrade to use the 10.0 version of Autonomy (after you have implemented 8.1 Autonomy with 9.2):
com.bea.query.* classes or any calls to the Autonomy client APIs in your applications and replace them with the appropriate calls to the 10.0 version of the Autonomy API.autonomyCompat.jar and autonomyClient1.5.0.jar file from the app-inf/lib directory.After the upgrade is complete, you must manually re-enter the passwords for your third-party repositories using the Administration Console; see the Content Management Guide 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 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 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:
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..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. 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 Version 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 9.2 Portlet Guide for instructions and an example.
Producer and consumer applications developed with WebLogic Portal 10.3 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 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 Federated Portals Guide.
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:
.portal file for a directive.page element. If that element is present, obtain the encoding from an attribute there.<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 the 10.3 Portal Development Guide for instructions on setting encoding and editing encoding in Workshop for WebLogic.
For compatibility with 8.1 and prior releases, and to support the few desirable uses of a disconnected desktop, WebLogic Portal 10.3 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 standlone 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, 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, 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.
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 Production Operations Guide.
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. 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 is identical to the procedure for updating from 8.1 to 10.3. See Upgrading Federated Portals from 8.1 to 10.3 for detailed instructions.
Your WebLogic Portal 9.2 or 9.2 MP1 UUP automatically works in WebLogic Portal 10.3. 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 and is still deprecated.
For more details, see Disconnected Desktop Requires desktopStateShared Property.
Upgrading search services involves updating your Autonomy configuration files and re-indexing your content.
Optionally, you can choose to migrate your existing Autonomy installation to use the 10.0 Autonomy installation directory. WebLogic Portal 10.3 ships with the same version of Autonomy as was shipped with WebLogic Portal 9.2, but the installation directory has changed. The new installation directory is: <WLPORTAL_HOME>\content-mgmt\thirdparty\autonomy-wlp10.
For production environments, you should continue to use the 10.3 installation directory (<WLPORTAL_HOME>\content-mgmt\thirdparty\autonomy-wlp10).
For development environments, Oracle recommends discontinuing the use the of the previous installation directory and using the new installation directory.
New multiple language search, query, and indexing capabilities have been added. The default 10.3 configuration supports the 9.2 configuration without alteration. For more information about the new capabilities, see Multi-language Searching and Indexing in Integrating Search.
| Note: | You MUST re-index your WLP content within your production environment; see the Integrating Search Guide for detailed instructions. |
In WebLogic Portal 9.2, CM full-text search connects to Autonomy during startup if the repository configuration has both of the following settings:
In WebLogic Portal 10.3, the settings for connections require:
The 10.3 settings more accurately reflect that CM full-text search is being used for a repository.
Because a WLP 9.2 full-text search application requires search-indexing-is-enabled=TRUE to use CM full-text search indexing, this setting already applies. However, you should verify the 10.3 repository configuration and update if necessary.
Update all of necessary Autonomy configuration files to use the new location, see Configuring Autonomy on Your Target Server” in the Integrating Search Guide for more details on Autonomy configuration files.
To continue to support double-quotes in your search queries, you must make the following changes to your BEACMRepoFetch.cfg file.
To support double-quotes (for example, “quotes”):
To continue support of querying Japanese characters, you must make the following modifications to your AutonomyIDOLServer.cfg file:
[FieldProcessing] section, do the following:[FieldProcessing] Number field value by one.19=SetLanguage using one number greater than the largest number listed in the [FieldProcessing] section.For example, change from this:
[FieldProcessing]
Number=19
0=SetIndexFields
...
18=SetMoreReferenceFields
[FieldProcessing]
Number=20
0=SetIndexFields
...
18=SetMoreReferenceFields
19=SetLanguage
[Properties] section, add the following section:[SetLanguage]
Property=LanguageFields
PropertyFieldCSVs=*/DRELANGUAGETYPE
[Properties] section, add a line of the form 19=LanguageFields using one number greater than the largest number listed in the [Properties] section.For example, change from this:
[Properties]
0=IndexFields
...
18=MoreReferenceFields
[Properties]
0=IndexFields
...
18=MoreReferenceFields
19=LanguageFields
[Security] section, add the following section:[LanguageFields]
LanguageType=TRUE
| Note: | Additional Japanese language and encoding functionality has been added to the 10.3 installation for searching, queries, and indexing. For more information about the new capabilities, see Multi-language Searching and Indexing in Integrating Search. |
Optionally, you can migrate your 9.2 Autonomy configuration to the 10.3 installation.
| Note: | For upgraded production environments, Oracle recommends continuing to use the existing 9.2 Autonomy location. |
To migrate your 9.2 Autonomy configuration and data to the new 10.3 location:
On the IDOL server, copy the following folders from the 9.2 location to the 10.3 location.
\\wlp-92\IDOLserver\IDOL\content\ folder, copy the following subfolders to the new content folder in the \\wlp-10\IDOLserver\IDOL\content\ location, and copy the following subfolders to the new content \\wlp-102\IDOLserver\IDOL\content\ location:\\wlp-92\IDOLserver\IDOL\indextasks\ folder, copy the following subfolders to the new Portal 10.3 \\wlp-103\IDOLserver\IDOL\indextasks\ folder:\\wlp-92\IDOLserver\IDOL\agentstore\ folder, copy the following subfolders to the new Portal 10.3 \\wlp-103\IDOLserver\IDOL\agentstore\ folder:\\wlp-92\IDOLserver\IDOL\category\ folder, copy the following subfolders to the new Portal 10.3 \\wlp-103\IDOLserver\IDOL\category\ folder:You need to export all indexed data from your 9.2 IDOL Server and re-import it into the 10.3 location.
Use the following command from your browser to export indexed content. Use the correct host name and port for your Autonomy configuration. You also need to indicate a file name, including a directory, to which to index content.
http://host:port/DREEXPORTIDX?FileName<filename>&Compress<true\false>
After exporting your indexed data from the 9.2 location, use the following command to import the content to the new WebLogic Portal 10.3 location. Use the correct host name and port for your Autonomy configuration and the file you created when you exported your data.
http://host:port/DREADD?<filename>
After completing the above sections, you must re-index your WLP content. For detailed instructions on re-indexing WLP content, see the Integrating Search Guide.
Producer and consumer applications developed with WebLogic Portal 10.3 are compatible with producers and consumers developed with WebLogic Portal 9.2. That is, a portal developed with WebLogic Portal 10.3 can consume portlets deployed in a WebLogic Portal 9.2 domain. Similarly, portlets exposed in a WebLogic Portal 10.3 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, or 10.3 consumer, you need to follow the procedures outlined the chapter “Establishing WSRP Security with SAML” in the Federated Portals Guide.
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 Workshop for WebLogic, 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 propagation tools.
|