Skip navigation.

eDocs Home > BEA WebLogic Portal 8.1 Documentation > Upgrade Guide > Functional Changes Affecting Your WebLogic Portal Environment

Upgrade Guide

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Functional Changes Affecting Your WebLogic Portal Environment

This appendix describes functional changes in WebLogic Portal Version 8.1 through 8.1 SP5 that affect your upgraded environment and might require that you perform manual tasks.

For additional information on new features in WebLogic Portal, see the WebLogic Platform Release Notes at:

http://download.oracle.com/docs/cd/E13196_01/platform/docs81/relnotes/relnotes.html.

 

Portlet State Persistence (Base Release, SP5)

In WebLogic Portal 7.0, minimized portlet states were persisted in the database, but in WebLogic Portal 8.1 and service packs they are persisted only for the session. This section describes a way to allow database persistence of the portlet state, based on the following new API method that was added in the WindowBackingContext in Service Pack 5:

public void setupStateChangeEventFromParent(String stateValue)

You can use this method in a backing file to change the state of portlets from a parent control, such as a desktop, book, or page. This way, one backing file at the desktop level can control the states of all portlets under the desktop.

A sample backing file that performs this task is provided as a sample in the dev2dev area of the BEA web site. The implementation described in this section is based on the sample backing file. Because the code for this solution is provided in a backing file, this code can be changed/updated as needed within your application.

This implementation utilizes the EntityPropertyManager to store the portlet states in the PROPERTY_KEY and PROPERTY_VALUE tables. The property names are set dynamically using the portal, desktop, and portlet labels and are mapped to each user who changes the state.

To set up portlet state persistence using the sample backing file, follow these steps:

  1. In WebLogic Workshop, create a property set named portletStateValue.
    1. Right-click portalApp/data/userprofiles and select New > User Profile Property Set.
    2. Name the property set portletStateValue.usr and click Create.

    Nothing else is required for this property set—you will use it as a key for storing the portlet state.

    This portletStateValue key is used in the backing file as a static final string variable. You can change the name of the property set if desired; if you do so, remember to update the string in the backing file.

  2. Create the following directory under your portal web application:

    3. web-inf/src/backing/statemgmt

  3. Copy the dev2dev sample Java backing file (PortletStateMgmtDesktopBacking.java) to the directory you created in the previous step.

    4. This file contains comments explaining the logic for persisting and restoring the portlet state.

  4. In WebLogic Workshop, open the .portal file and select the desktop. In the property editor, enter the following for Backing File:

    5. backing.statemgmt.PortletStateMgmtDesktopBacking

Important note: This implementation was tested using the sample.portal that is provided by default, and uses the login portlet example. When logging in, the handlePostbackData method is called in the backing file, and _nfpb=true is set in the URL. If you are using a different login mechanism, make sure handlePostbackData is called when the portal is being rendered the first time after login.

 

New Option for Request Attribute Persistence (SP4)

In Version 8.1 SP4, a request persistence optimization enhancement led to the addition of a new attribute for page flow and struts portlets. The new requestAttrPersistence attribute allows you to capture the state of the request immediately after an action has run, so that a JSP can depend on that state, and can be rendered again any number of times to support page refreshes.

Although the default value of session in the new attribute preserves the existing behavior, if you attempt to modify the state of the request within the JSP, the new behavior will not allow this implementation to work. Ideally, you should move any logic that modifies the state of the request out of the JSP and into the action. A less desirable workaround would be to set the Request Attribute Persistence attribute to none to disable WebLogic Portal's automatic persistence functionality.

For more information about the Request Attribute Persistence attribute, refer to the WebLogic Workshop online help at:

http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/portal/buildportals/portalPropertiesPortlet.html

 

New Generic URL Tag (SP6)

In WebLogic Portal SP6, a new method is available for the GenericURL class to override the <generate-xml-amp-entity> attribute in the url-template-config.xml file. This method was created to allow for programmatic use of URLs.

The new GenericURL.setForcedAmpForm(boolean) provides a public API to set the URL query separator. This overrides the default mechanisms for determining ampersand entity or character usage. Passing in true generates the URL with ampersand entities ("&amp;") and passing in false generates the URL with the ampersand character ("&").

The following code fragment shows how to override a true value in the <generate-xml-amp-entity> element:

PageURL postUrl = PageURL.createPageURL(getRequest(), getResponse());
   postUrl.setPageLabel("Test_page_6");
   postUrl.setForcedAmpForm(false);
   postUrl.addParameter("test","test",true);

The resulting URL would look like this:

http://localhost:7001/test/test.portal?_nfpb=true&;_pageLabel=Test_page_6&test=test

A corresponding attribute for the GenericURL JSP tag, called forcedAmpForm, was also added. This new attribute was added to the following tags:

The following code fragment is from the tag library definition for each of the above JSP tags:

<attribute
   <name>forcedAmpForm</name>
   <required>false</required>
   <rtexprvalue>true</rtexprvalue>
   <description>Forces the form of query separators used for this URL.
   This overrides the natural mechanisms for determining ampersand entity
   or character usage based on document type and/or configuration.
   If the value 'true' is used, then "&amp;" will be the separator.
   If 'false' is used, then the "&" character will be the    separator.</description>
</attribute>

 

Oracle 10g R2 Database Requires Manual Privilege Setup

As described in Oracle Note 317258.1, Oracle changed their use of predefined database roles in the 10g R2 version to provide more security. The CONNECT role now provides only CREATE SESSION privileges; the other associated privileges have been removed.

You must now explicitly grant the CREATE VIEW privilege for Oracle 10g R2 databases.

 

Associating Portlets with Pages (Base Release, SP5)

In WebLogic Portal 7.0, the portal administrator had the ability to restrict portlets so that they could display only on particular pages. In WebLogic Portal 8.1, this functionality is not directly available because users can now utilize visitor tools to display portlets (to which they are entitled) on any available page. This section describes a way to allow portlet association with particular pages, based on the following new method that was added to PortalVisitorManager in Service Pack 5:

public static String[] generateOnePortletCategoryArray(String webAppName, String pageLabel, String indentStr, HttpServletRequest request)

The new method in Service Pack 5 that achieves similar functionality to that of WebLogic Portal 7.0 uses portlet categories and modified visitor tools. The administrator places portlets into a category and associates it using a unique page label; the visitor tools then filter the portlet list to include only those in the appropriate category.

Note: To use this implementation, all pages within a portal with visitor tools customization/capability must be assigned a portlet category to allow the code to find the portlets for the individual pages.

You can view a code example that uses portlet categories and modified visitor tools on the dev2dev web site at: https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=S174.

 

Mandatory Portlets (8.1 Base Release)

In WebLogic Portal 7.0, the portal administrator had the ability set a portlet as "Mandatory" to prevent certain portlets from being removed as a result of a user's customizations; however, using the "Mandatory" flag in 7.0 did not prevent a user from (for example) moving the portlet to the bottom of a page, which could result in the portlet not being visible without scrolling down the page.

In WebLogic Portal 8.1, locking placeholders were introduced to require a fixed position of the portlet on a page. (For instructions on using locking placeholders, see the Administration Console online help at http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/adminportal/help/PM_PortletLock.html.)

To create mandatory portlets that appear in a specific position on a web page, you can use a combination of a locking placeholder and a custom layout; you lock a placeholder for a column in the layout for the page, and place mandatory portlets in that placeholder. You use custom layouts to create the layout you need for this purpose.

The following white paper includes instructions on creating custom layouts:

http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/whitepapers/netix/body.html

 

Upgrading Simple Producers from Service Pack 3

When upgrading a simple producer from WebLogic Portal Service Pack 3 to a later service pack, WSRP producer web application libraries are not automatically updated. If you upgrade from SP3 to a later service pack, you must perform the following steps to ensure that your simple producer continues to function properly as a WSRP producer.

Note: A simple producer is a non-portal web application. For more information on simple producers, see Producers in Using WSRP with WebLogic Portal.

  1. Perform the normal procedures for upgrading a WebLogic Portal application from SP3 to a later service pack.
  2. Copy the following files into the WEB-INF/lib directory of your web application:
BEAHOME/weblogic81/portal/lib/netuix/web/netui-adapter.jar
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter.jar
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter-html.tld
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter-naming.tld
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter-nested.tld
BEAHOME/weblogic81/portal/lib/netuix/system/ext/web/struts-adapter-tiles.tld
BEAHOME/weblogic81/portal/lib/wsrp/wsrp-producer.jar
BEAHOME/weblogic81/portal/lib/wsrp/adapters/wsrp-jpf-adapter.jar
BEAHOME/weblogic81/portal/lib/wsrp/adapters/wsrp-struts-adapter.jar
  1. Redeploy the WSRP producer web application.

 

Aggressive Control Tree Persistence (SP4)

SP4 contains Portal Framework changes that significantly improve performance. Most of these changes have no effect on how you implement WebLogic Portal; however, because of the new aggressive control tree state management improvements, you must be particularly careful not to duplicate session IDs within your portal/desktop. If you use duplicate IDs, unknown effects might occur and the resulting problems would be difficult to diagnose.

 

Content Management Portlet (SP4)

The Content Management portlet now uses wlp-admin.jar rather than cms_tools.jar. If you added the Content Management portlet to your project in a previous Service Pack, you must delete cms_tools.jar and add the SP4 version of wlp-admin.jar to the following directory:

<portal_application>\<project>\WEB-INF\lib\

You can find the SP4 version of the wlp-admin.jar in the following directory:

WL_HOME\samples\portal\portalApp\sampleportal\WEB-INF\lib

For more information on setting up a Content Management portlet, see the WebLogic Workshop online help.

 

URL Template File Updates (SP4)

The WEB-INF\url-template-config.xml file is automatically created in a portal Web project. The url-template-config.xml file contains multiple URL "templates," each with a unique name. Those template URLs contain variables such as url:domain and url:port that are read in from the active server.

If you are upgrading a web application from a previous service pack, review the following sections to determine if you need to edit the url-template-config.xml file.

Creating New Portals Using Administration Portal

When you create new portals with the Administration Portal, the generated url-template-config.xml file does not contain the {url:currentPage} variable. Add this variable to the file to allow the tree optimization feature to work, and to ensure full function of the Back button.

URL Template File Update for WSRP

The url-template-config.xml file contains URL templates and variables for remote portlets in a WSRP portal Web project. You must make the following two changes in this file for each WSRP URL template, so that the BEA-provided consumer will be able to handle mode changes and state changes from non-BEA producers:

Updates for Java Portlets

If you are using or you plan to use Java portlets (JSR 168 portlets), edit the url-template-config.xml file to match the new content in the SP4 version of this file; add/update the content as the following example shows:

<url-template name="portlet-secure-default">
https://{url:domain}:{url:securePort}/{url:path}?{url:queryString}{url:currentPage}
</url-template>
<!-- Map Java portlet URLs to the templates defined above. -->
<java-portlet-url-templates>
<url-template-ref type="action" name="portlet-action"/>
<url-template-ref type="secure-action" name="portlet-secure-action"/>
<url-template-ref type="resource" name="portlet-resource"/>
<url-template-ref type="secure-resource" name="portlet-secure-resource"/>
<url-template-ref type="render" name="portlet-default"/>
<url-template-ref type="secure-render" name="portlet-secure-default"/>
</java-portlet-url-templates>

 

Portlet Preferences Behavior on Server Restart (SP4)

Prior to Service Pack 4, when the server was bounced or redeployed, the preferences in the .portlet file always overrode the preferences in the database, so administrator additions and changes to any portlet preferences were lost on a server restart.

A new option allows you to control the way in which portlet preferences are reloaded on server restart. You implement this control using the "master" attribute on the "propagate-preferences-on-deploy" element in the WEB-INF/netuix-config.xml file.

Possible values for the master attribute are:

file

Provides the same behavior as in previous versions. The preferences in the file system always take precedence. To preserve existing behavior, select this value.

database

In the case of a restart, the values in the database always takes precedence. In the case of a first time startup, the database is seeded from the .portlet files.

both

The default behavior if the attribute is missing. The .portlet preferences are merged with the database preferences, with the database values taking precedence over the .portlet file's values.

The following example shows the element with an attribute value of both:

<customization>

<enable>true</enable>

<propagate-preferences-on-deploy propagate-to-instances="true" master="both"/> <reload-database-on-redeploy reload="false"/> </customization>

 

Entitlements Data Source (SP4)

The policy reference RDBMS persistence feature is a performance enhancement in SP4. If you are upgrading from a previous service pack and upgrading a pre-SP4 domain, you must add a new JNDI name, which is used to look up the p13nDataSource.

To perform this task using the WebLogic Server console:

  1. In the Services Configurations section, select JDBC Data Sources.
  2. In the Name column, select p13nDataSource.
  3. Append ;p13n.entitlementsDataSource to the JNDI Name: field and click Apply.
  4. Restart the server.

 

Storage of Policy Reference Data in RDBMS (SP4)

Starting with WebLogic Portal 8.1 SP4, new database tables store entitlement data and Delegated Administration security policy reference data. Policy storage remains within LDAP, but policy reference data is stored in the RDBMS. When you access the Administration Portal for the first time in an upgraded domain, the system performs an automatic migration of this policy reference data.

If you want to prevent the migration of data to the new database tables, set the following Java environment parameter in the startWebLogic.cmd/.sh file:

-Dp13n.policyRef.LdapPersistence=Y

For details on the new database tables, see the Data Dictionary in the Portal Database Administration Guide:

http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/db/4Schemas.html

 

Using Role Caching with Entitlements (SP4)

Starting with WebLogic Portal 8.1 SP4, role values are cached automatically. Normally you do not need to change this setting. However, if you decide to define roles with expressions whose evaluation changes within the course of processing a request, you may need to disable this setting.

To disable role caching, edit the web.xml file for the respective application. For instructions on this task, see the WebLogic Portal Performance Tuning Guide at http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/perftune/4PortalApplication.html#1074386.

 

Setting up JDBC Connection Polling (SP4)

In Service Pack 4, JDBC connection polling was added to the RDBMS authentication provider to keep JDBC connections active during long periods of inactivity. This was done to prevent firewalls or databases from timing out JDBC connections held by the internal pooling mechanism in the RDBMS authentication provider.

When configuring your RDBMS authentication provider you must enable connection polling. The WebLogic Server console includes the following two new attributes that you can set when you create/configure your provider:

 

Portal Projects in Source Control (SP4)

BEA recommends managing your portal project using a source control system. For releases prior to SP4, BEA recommended not storing the class files in the path *WEB-INF/classes* because these are built automatically by WebLogic Workshop. However, in SP4 several new classes were added in the path *WEB-INF/classes/com/bea/jsptools/portal* for which source files are not provided, specifically:

Because of this change, SP4 portal projects based on WebLogic Workshop will not build successfully when extracted from their source control repository.

To ensure a successful build of your portal project while using source control, you can create a .jar file containing the class files listed above, and check the .jar file into the source control system repository.

 

Using New Proxy Portlet Cache (SP6)

In order to render each proxy portlet, WebLogic Portal makes several database calls to obtain proxy portlet information. WebLogic Portal 8.1 SP6 includes a new p13n cache called proxyPortletCache that allows you to cache the results of this getProxyPortlet query. BEA recommends that you use this cache if you are using federated portals (WSRP) and you have many proxy (remote) portlets; each environment is different, but an example might be an implementation with over 100 proxy portlets.

To customize the proxy portlet cache setting, edit the meta-inf/application-config.xml file and add the following entry:

<Cache MaxEntries="max_number_of_proxy_portlets" Name="proxyPortletCache"

Notes="This caches the ProxyPortlets from getProxyPortlet query" TimeToLive="ttl_value"/>

For the value max_number_of_proxy_portlets enter a number, such as 150.

For the value ttl_value, enter the timeout value in milliseconds; a value of -1 causes the cache to never expire.

If you add this entry to the application-config.xml file, you can then configure or flush the cache using the WebLogic Portal Administration Console.

If you do not add this entry to the file, the cache will not be configurable using the Administration Console; the cache will still be used, with the following default values:

Time to live = 3600000 (one hour, in milliseconds)

Maximum entries = 100

Note: The proxy portlet cache will automatically be used only in new web applications. Even if you update an existing web application using the File > Update Portal Libraries selection, the proxy portlet cache will not be used unless you manually add the required entry to the application-config.xml file.

 

Using Content Query Expressions (SP6)

When you execute a Content Query expression in SP6, the order of precedence is not maintained and the expression generates incorrectly. The following expression (a && (b || c) is evaluated as (a && b || c).

This problem can be fixed in SP6 so that the order of precedence is maintained when you execute a Content Query expression. A system property was added so that the expression is evaluated the same as it was for 8.1 SP5 or earlier. Type the following to correctly generate a Content Query expression:

-Denable.content.rule.fix=true

 

Propagating Request Parameters from WSRP Requests (SP6)

Request parameters are no longer implicitly propagated from one WSRP request to the next. This issue impacts you if you have a patch for CR 254373. It affects all platforms.

Prior to the fix for CR254373, the portal framework would automatically add all request parameters to the WSRP navigationState URL. This action caused a problem because the URL could become too large. CR254373 removed this bug, but it caused pageflows to fail after the fix was applied. The steps involved included submitting a form to a pageflow action, the action then forwarded to a result.jsp, which then displayed the form contents by pulling them out of the request. This works in a standard pageflow but fails when the pageflow is accessed through a WSRP consumer portlet, because the submission of the form and the follow up display of the results requires two requests from the consumer to the producer (although it still appears to be a single request from the stand point a user interacting with the consumer). Submission of the form from the consumer to the producer is handled by a performBlockingInteraction() call. When that call completes, the consumer then follows up with a getMarkup() request to the producer that returns the markup for the result.jsp page. However, since the request parameters are not implicitly propagated from one request to the next, the form parameters are no longer present when the getMarkup() request is processed. The pageflow example described earlier is one way to demonstrate this issue, but it applies to any case where a performBlockingInteraction()call is made.

The workaround is not really a workaround; it is the proper way to implement this functionality. Implementers simply need to explicitly propagate the parameters they wish to keep in the request. Referring back to the pageflow example described above, there are two simple solutions that could be used to fix the implementation. In the first solution the pageflow action that receives the submitted form can simply pass it along by explicitly including the form in the Forward object that is returned by the action. This can be done using a netui ActionForm object, or individual parameter name value pairs can be included as pageInputs in the Forward object. The results.jsp should then retrieve the items in a manner suitable to the method used. Another possible solution is for the pageflow to hold onto the desired parameters as part of its state. That is the action that receives the form retrieves the parameters of interest from the ActionForm or request, assigns the values to instance variables and provides access to those value through getters on the pageflow. The result.jsp can then access the values need using those getters.

 

Skip navigation bar  Back to Top Previous Next