Portal Development Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Upgrading WebLogic Portal Projects to Version 9.2

The BEA Workshop for WebLogic Platform Programmer’s Guide, available as part of the Workshop for WebLogic help, contains several useful topics that you should review as you prepare to upgrade your portal application. The Workshop for WebLogic documentation includes step-by-step instructions for using the Import Wizard, and detailed information about what happens during the upgrade process and any required manual pre- or post-upgrade tasks.

It is extremely important that you become familiar with the Workshop for WebLogic upgrade steps, and any related limitations, before you attempt to upgrade a WebLogic Portal application from Version 8.1 4 or 8.1.5 to Version 9.2. Before proceeding, refer to the Workshop for WebLogic documentation on e-docs or by choosing Help > Help Contents > BEA Workshop for WebLogic Platform Programmer’s Guide in the main menu of the product.

The Workshop for WebLogic upgrade documentation assumes that your application was developed using WebLogic Workshop Version 8.1. If it was not, you must refactor your code so that it builds and runs in the WebLogic Workshop IDE Version 8.1 SP4 or SP5 before using the tools described here to upgrade to Workshop for WebLogic Version 9.2.

This chapter focuses on topics that are specifically related to upgrading WebLogic Portal applications, and contains the following sections:

 


Version 8.1 Features Not Supported in Version 9.2

Webflows and pipelines were deprecated in Version 8.1 and are no longer supported; use page flows in place of these deprecated features.

 


Upgrade Considerations and Tips

The following sections describe some considerations and tips that might be useful when you upgrade portal applications, and it describes some situations where you might need to perform some manual tasks after upgrading your portal application.

This section contains the following topics:

Command-Based and Ant Task Upgrade Not Supported

Workshop for WebLogic provides a command-driven upgrade (upgradeStarter) and an ant task-based upgrade. WebLogic Portal does not support these upgrade alternatives; you must use the Import Wizard.

Enabling Communities Features in Upgraded Visitor Tools

Unmodified Visitor Tools code from WebLogic Portal 8.1.4 or later is upgraded as part of Import Wizard processing. However, the new Version 9.2 communities-based components are disabled by default, because projects developed using Version 8.1.x are not communities-aware.

As part of the upgrade process, the Import Wizard creates a communities-config.xml file in the EAR project /META-INF directory that defines whether or not the communities-related Visitor Tools are enabled. To enable this functionality, set the flag in the enable-community-tools attribute to true, as shown in the following example:

<?xml version="1.0" encoding="UTF-8"?>

<communities-config xmlns="http://www.bea.com/ns/portal/90/communities-config">

   <enable-community-tools>true</enable-community-tools>

</communities-config>

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 9.2, both files are now XML.

For Version 9.2, it is necessary to use skin.xml and skeleton.xml to take advantage of new Look & Feel features, although you can still use legacy configurations. Upgrading your old .properties files is required.

To upgrade a WebLogic Portal 8.1 Look & Feel to the WebLogic Portal 9.2 format:

  1. Make sure the portal application containing the Look & Feel has been converted to WebLogic Portal 9.2, as described in this chapter and in the Workshop for WebLogic documentation.
  2. Open the Look & Feel file (.laf file).
  3. WebLogic Portal automatically upgrades the associated .properties file; informational messages describe the change that occurs during upgrade. Figure 5-1 shows an example:

    Figure 5-1 Conversion of Properties File when Look & Feel File is Opened


    Conversion of Properties File when Look & Feel File is Opened

  4. Click OK to complete the upgrade.

Upgrading Custom Controls that Have Custom Properties

Version 8.1 custom control annotation definitions are not upgraded to Version 9.2. The means for defining annotations is based on the Java 5 annotations model. To upgrade controls written for version 8.1, you must rewrite the annotations definition in keeping with the new model.

For more information on upgrading your custom annotations, take a look at the Apache Beehive source code for its system controls. These provide annotations that use the new model.

For information on how the control context APIs have changed from Version 8.1, see “Handling Context API Changes” in the Workshop for WebLogic online help.

Upgrading Tuned Thread Pools for Forked Portlets

If you optimized the thread pool used for an 8.1 application that uses forked rendering or forked pre-rendering, and you want to keep those optimizations in the upgraded application, you will need to perform some manual tasks after upgrading.

In Version 9.2, WebLogic Portal uses WebLogic Server's CommonJ WorkManager infrastructure for forked portlet pre-render and render. WorkManagers have similar but not identical configuration parameters, behavior, and deployment options. When you upgrade an 8.1.4+ application, any existing customizations to the portalRenderQueue thread pool will not be automatically applied to the default WorkManager used for forking. To tune this WorkManager, configure a WorkManager and associate it with the name wm/portalRenderQueueWorkManager. For more information about WorkManagers and thread usage in WebLogic Server 9.2, refer to “Using Work Managers to Optimize Scheduled Work” in the WebLogic Server documentation.

Upgraded Applications Use Struts 1.1 and Related J2EE Libraries

The Import Wizard includes the Struts 1.1 shared J2EE library for upgraded applications. The Struts 1.1 J2EE library is used to maintain the operability of your upgraded application; before an upgraded application can use Struts 1.2, any code in page flows or portlets with explicit dependencies on Struts 1.1 would need to be manually updated. (For more information, refer to Changes in Behavior Between Struts 1.1 and 1.2.

For new portal web projects, the Struts 1.2 shared J2EE library is included by default, but you can choose Struts 1.1 if desired. BEA strongly recommends that you keep the default setting to use Struts 1.2 with new applications. Even with upgraded applications, it would be beneficial to use Struts 1.2 if possible, and you might want to experiment with Struts1.2 to see if any explicit dependencies on Struts 1.1 actually exist.

Changes in Behavior Between Struts 1.1 and 1.2

WebLogic Portal support for Struts is slightly different if you upgrade to Struts 1.2.

Struts 1.1 support in WebLogic Portal will be the same as in previous releases, with the struts-adapter taglibs mapped to URIs using web.xml. In this case, you should use the struts-1.1.war J2EE library instead of the new struts-1.2.war J2EE library.

For applications 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. In the case of WebLogic Portal, these are in struts-adapter.jar, in the path META-INF/tlds.

You can choose to use one of these two methods to upgrade to Struts 1.2:

Ampersand Entities in Portal URLs

In past releases, WebLogic Portal used the configuration file url-template-config.xml for configuring the form of WebLogic Portal-generated URLs. WebLogic Portal now uses the Beehive equivalent: beehive-url-template-config.xml. The previous configuration file contained an element (generate-xml-amp-entity) that caused URLs to be generated with ampersand entities instead of characters for parameter separators, that is:

http://www...?arg1=foo&amp;arg2=bar (entity)

instead of:

http://www...?arg1=foo&arg2=bar (character)

In the absence of this configuration element, URLs were generated with ampersand characters.

The Beehive equivalent configuration element for ampersand entities is located in the NetUI configuration file, beehive-netui-config.xml. The Beehive default for ampersand entities is the opposite of the previous Portal default; in the absence of the configuration element, URLs are generated with ampersand entities.

Portal Framework now uses the NetUI configuration file as the source for this configuration element, and also uses the Beehive semantics. This means that by default, URLs generated by Portal contain ampersand entities. Note that this applies only to HTML configurations – XHTML configurations force ampersand entities in URLs, regardless of configuration setting.

If cases exist where you want to ensure that URLs are generated with characters rather than ampersand entities, you must add that configuration element to the beehive-netui-config.xml file.

Upgrading Individual application-config.xml Files Later

Applications created using WebLogic Portal Version 8.1.x used the file META-INF/application-config.xml for configuration of various MBeans. In Version 9.2, MBeans have been changed to descriptor beans. Settings previously contained within application-config.xml are now in the appropriate descriptor bean configuration files, including:

When you import a Version 8.1.4 or later application into Workshop for WebLogic, the import process performs the necessary conversion. For individual instances of the Version 8.1 application-config.xml file that you might want to use, you can right-click the file name in the Package Explorer to access the Upgrade context menu, which will convert the file.

Correcting Duplicate Portlet Category Names Before Propagating an Upgraded Application

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.


  Back to Top       Previous  Next