|
|
This appendix describes functional changes in WebLogic Portal Version 9.2 and Version 9.2 MP1 that affect your upgraded environment and might require you to perform manual tasks.
This chapter includes the following sections:
The following changes have been introduced in WLP 9.2 MP1.
The domain upgrade tool provided in 9.2 MP1 will take an existing config.xml file and update the implementation version for all the appropriate product library modules. For information on when and how to run the tool, see Upgrading Domains to a Maintenance Pack.
Rich text content in GroupSpace is susceptible to cross-site scripting (XSS) attacks. Because rich text content in GroupSpace is actually HTML, it is possible for users to add JavaScript code that will execute in other users' browsers when the HTML is rendered. It is possible that the JavaScript could contain malicious code, performing operations such as redirecting users' browsers. Examples of rich text content in GroupSpace include the body field in GroupNotes and the Notes field in Issues.
In WebLogic Portal 9.2 MP1, rich-text editing is controlled through the web.xml file by the administrator, and accordingly, the user interface for portal development displays options for rich-text and HTML editing.
The following use cases are affected by the web.xml.
com.bea.apps.groupspace.RichTextEditorEnabled parameter is set to "true" in web.xml, then the rich-text editor is made available based on the Portlet Preference, RichTextEditorEnabled. If the com.bea.apps.groupspace.RichTextEditorEnabled parameter is not set, or is set to any value other than "true", the Portal Preference is not considered, and the rich-text editor is unavailable. If the value of this parameter is "true", then the Portlet Preference will determine if the editor is available. web.xml, called com.bea.apps.pgroupspace.RichTextEditorHTMLToolBarEnabled, and a Portlet Preference, RichTextEditorHTMLToolBarEnabled control whether HTML can be entered directly or not. If the web.xml parameter is set to true, and the Portlet Preference is enabled, then the UI displays the HTML option, which allows entering HTML content in the rich-text editor.collaboration.RichTextEditorEnabled parameter is to "true" in web.xml, then the rich-text editor is made available based on the Portlet Preference, collaboration.rich_text.enabled. If the parameter is not set in web.xml, or it is set to any other value than "true", then the Portlet Preference is not considered and the rich-text editor is unavailable. If the value of this parameter is "true", then the Portlet Preference will determine if the editor is available. Collaboration portlets do not support entering HTML directly in the rich-text editor.
This section describes the default settings related to the availability of the rich-text editor and HTML input.
For out of the box GroupSpace sample, the rich-text editor will be enabled. For all other web projects, by default, the rich-text editor is not enabled for any portlet (GroupSpace or Collaboration). The administrator can change the settings, keeping in view the security risk.
A web.xml snippet will be included in that web application with the following settings:
com.bea.apps.groupspace.RichTextEditorEnabled = "true"
collaboration.RichTextEditorEnabled = "true"
com.bea.apps.groupspace.RichTextEditorHTMLToolBarEnabled = "true"
| Note: | Web projects created by customers in WebLogic Workshop will not contain any of the above parameters, and hence, the rich-text editor is disabled by default. |
For GroupSpace (GroupNotes, Issues, Announcements, View Announcements), the Portlet Preference for RichTextEditorEnabled is "true" and for RichTextEditorHTMLToolBarEnabled is "false".
In the case of projects created by developers, the web.xml includes the following values:
com.bea.apps.groupspace.RichTextEditorEnabled = NOT SET
collaboration.RichTextEditorEnabled = NOT SET
com.bea.apps.groupspace.RichTextEditorHTMLToolBarEnabled = NOT SET
| Note: | NOT SET means "false". |
For GroupSpace, the Portlet Preference for RichTextEditorEnabled is "true" and for RichTextEditorHTMLToolBarEnabled is "false".
For Collaboration Portlets, Portlet Preference for collaboration.RichTextEditorEnabled is "true" and HTML editing is not available.
| Notes: |
| Note: | Modifying the parameter setting value in web.xml requires a redeployment of the web application in order to take effect. |
| Note: | Portal Preference values are cached in the pageflow. Therefore, after changing a preference value via the Admin Portal, you must log out of GroupSpace and log back in to see the effect of the new preference value. |
| Caution: | These settings, in web.xml and at the Portlet Preference level, are not meant to be switched back-and-forth. You must decide at the time of deployment how you want the rich-text editor to be used and should establish these settings prior to using of the GroupSpace instance. If you create content with the rich-text editor, and then disable the editor, the display of the content can be illegible. |
| Caution: | For example, when creating/editing content in the rich-text editor, new lines are represented as <br> tags. However, when the rich-text editor is disabled, these will be displayed as "<br>" rather than causing a new line. |
The ResourceProxyServlet sends back to the browser Set-Cookie from static resources it retrieves. This Set-Cookie comes from the producer and will overwrite the Set-Cookie already in the browser which denotes the consumer session. Hence, the session will be lost when the next request is received from the browser. Typically, setting the CookiePath would differentiate the Set-Cookies and solve the problem, but if that is not possible to do (for example, when you implement single sign-on in the same domain), the problem remains.
This problem has been resolved and a new system property is introduced, to prevent a sessions from being lost. Enabling the system property wlp.resource.proxy.servlet.block.response.headers blocks the ResourceProxyServlet from sending Set-Cookie header back to browser.
This allows you to keep the cookie names the same for both applications (as required for SSO) and still prevent the consumer's cookie from getting overwritten by the producer's cookie on the browser when a resource is returned.
For more information on setting the system property, see Configuring Session Cookies under http://download.oracle.com/docs/cd/E13218_01/wlp/docs92/federation/Chap-Best_Practices.html.
The following changes have been introduced in WLP 9.2 GA.
When you upgrade a UUP from WebLogic Portal 8.1, the p13n_ejb.jar file is deleted and replaced with a new WebLogic Portal 9.2 version of this 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).If you had a WebLogic Portal 8.1 Java project and you upgrade to Portal 9.2, the Import Wizard automatically creates a Utility project. A Utility project is used to develop general-purpose Java code that is not directly part of special entities (web services, controls, or EJBs, for example). See Chapter 8 in the Portal Development Guide for instructions on creating a Utility project.
Table A -1 lists some of the common WebLogic Portal J2EE libraries that you might want to add to a Utility Project after you upgrade.
Table A -1 Common WebLogic Portal Libraries To Add To Utility ProjectsSee the Portal Development Guide for more information.
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 9.2. 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 portal/thirdparty/autonomy-wlp92 directory. For more information about configuring Autonomy search, see the
WebLogic Portal 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 9.2 API and are NOT compatible with the 9.2 Autonomy engine. This means that some 9.2 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 9.2 application:
autonomyCompat.jar and autonomyClient.1.5.0.jar from weblogic_home/portal/lib/thirdparty/search/81-compat-only into the application_home/APP-INF/lib directory.The version 8.1 Autonomy APIs and engines are now running.
If you want to upgrade to use the 9.2 version of Autonomy, after you have completed the steps in Using 8.1 Search within a 9.2 Portal Application, you can reverse the implementation.
To upgrade to use the 9.2 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 9.2 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 9.2 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 9.2, both files are now XML, and both are required.
To upgrade a WebLogic Portal 8.1 Look & Feel to the WebLogic Portal 9.2 format:
The cm_taglib.jar is the tag library for the WebLogic Portal 7.0-based DocumentManager feature. The Import Wizard will not detect whether or not you have any JSPs that refer to this taglib, which has an unsupported taglib URI. 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 so that they use supported tags and APIs, and delete the file cm_taglib.jar.
WebLogic Portal support for Struts is slightly different in Version 9.2 if you upgrade to Struts 1.2.
Struts 1.1 support in WebLogic Portal is the same as in previous releases, with our 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 Version 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).
In Version 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.
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 Version 8.1 will continue to work if you depend on this behavior, but BEA recommends that you use a new method of persisting the portlet state.
In Version 9.2, you can persist the portlet state in the database by using the persistence-enabled attribute in the control-state-location element of the netuix-config.xml file.
Here is an example of the persistence-enabled attribute:
<session persistence-enabled="true"/>
If you set the persistence-enabled attribute to true, then the control tree state will be loaded from the database when a user logs in, and the new state will be stored when a user logs out. The control tree state is cleared when a user interacts with a portal.
The default and the only persistence type implemented is JDBC. The default implementation uses the BEA_PORTAL_FRAMEWORK_CONTROL_TREE_STATE property set of the user's ProfileWrapper; the ProfileWrapper must be created and stored in the user's http session. The ProfileWrapper is created by PortalServletFilter, which should be configured in the web.xml file. If the ProfileWrapper is not found in the user's session, the control tree state is not persisted.
| Note: | Page flow- and struts-related states are not persisted, as they are not part of the control tree state; page flow and struts portlets might not be in the exact same state when user logs out. |
The child elements reader-class-name/writer-class-name provide reader and writer class names for this state-location. If you want to customize reader/writer behavior, you can implement the ControlStateReader/ControlStateWriter interfaces and configure them in the netuix-config.xml file.
Producer and consumer applications developed with WebLogic Portal 9.2 are compatible with producers and consumers developed with WebLogic Portal 8.1. That is, a portal developed with WebLogic Portal 9.2 can consume portlets deployed in a WebLogic Portal 8.1 domain. Similarly, portlets exposed in a WebLogic Portal 9.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 Federated Portals Guide.
This section describes changes in how the encoding is set on the HTTP response.
In Version 8.1 of WebLogic Portal, the following method of setting encoding was used:
.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.
In Version 9.2 of WebLogic Portal, the following method of setting encoding is used:
netuix:desktop element for an encoding attribute, and use that value if present..portal file for the deprecated directive.page element. If that element is present, pick up the encoding from an attribute there.netuix-config.xml for a <defaultEncoding> element, and use the encoding attribute there.<encoding> element in the <jsp-param> section of the web.xml file.The old methods continue to work, but to eliminate any deprecation warnings, BEA recommends that you use the new mechanisms; for example:
<netuix:desktop ... encoding="UTF-8" />in your.portalfile
<defaultEncoding encoding="UTF-8" />in yournetuix-config.xmlfile
When you select the desktop element from the portal view or outline view while editing a .portal file, the workbench now includes a new encoding property in the property view. The value for a new portal defaults to UTF-8. You can edit the value using an editable drop-down menu.
The drop-down menu initially displays a list of all the basic IANA encoding values as well as the extended encodings for Chinese, Korean, and Japanese. The values presented in the list are descriptive display names that are converted to actual IANA names when saved to the .portal file.
If a desired value does not display in the drop-down menu, you can type it in. When you press Enter, the validator checks the encoding to verify that it is a valid and supported encoding. The value you enter can be from the extended encoding set and can be an IANA name, alias, or canonical name for the encoding. If the encoding fails validation, a warning message displays; you can choose to override the validation and accept the value anyway. The value will be stored as is, in the .portal file for the desktop encoding attribute.
For backward compatibility and to support the few desirable uses of a disconnected desktop, WebLogic Portal Version 9.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 standlone portlet—setting path or contextualPath causes the resulting URLs to become disassociated with the originating desktop.
In past 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 Version 9.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 Version 9.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.
The Propagation Utility web application, propagation.war, is obsolete in WebLogic Portal 9.2. This application that 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 9.2.
|