Skip navigation.

Upgrade Guide

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

Overview of the Upgrade Process from WebLogic Portal 7.0 SP2 to 8.1

This section provides an overview of the strategies and procedures for upgrading WebLogic Portal 7.0 SP2 applications to WebLogic Portal 8.1 and its associated service packs. The following topics are discussed:



To clarify the different activities described by this document, a brief list of terms is included:


Moving an application/domain from a third-party technology to a BEA product. (For example, migrating a customer from IBM, webMethods or "home grown" to BEA.)


Updating BEA platform (and components) from older release/Service Pack to newer release/Service Pack. This includes updating existing application/domain to run in a newer version, for example, 7.0 to 8.1.


(1) The capability of an application deployed in one release or service pack to communicate with another application that is deployed in a different release or service pack. (2) The capability of WebLogic Platform components to communicate with third-party software using standard protocols.


Application built using one release/Service Pack running in another release/Service Pack. This may or may not involve rebuilding the application.


Portal Version 7.0 SP2 to 8.1 Upgrade Process Overview

Two paths are available for upgrading your WebLogic Portal 7.0 SP2 portal web application to WebLogic Portal 8.1:


Comparing Supported Features

This section outlines significant feature changes between the WebLogic Portal 7.0 SP2 and the WebLogic 8.1 release. For detailed descriptions and implementation details, consult Framework Reference for Portal Upgrades from 7.0 to 8.1.

The portal framework in WebLogic Portal 7.0 has a one-to-one mapping with the portal it represents; this methodology adheres to the single portal per web application architecture. Changes made to this framework will impact the portal and all group portals, with limited provisions for changes based on runtime factors. This code was not originally designed to be modified by end users and was instead considered part of the product itself. However, users who wished to change the way that the portal behaved or make significant changes to the way that the portal looked were forced to modify this framework.

In WebLogic Portal 8.1, the framework has been designed to allow users to more readily modify the look and the feel of the product. Instead of the single collection of JSP files for a portal, any portal can use a look and feel, which in turn is comprised of a skin and a skeleton. The portal framework is an XML skeleton that replaces the framework JSPs, allowing users to easily modify the behavior of the portal without modifying the underlying BEA code.

Look and Feel

The look and feel of a portal is determined primarily by the code used to render the HTML, the styles used by the HTML, and the images displayed. In 7.0 only the skin could be changed to obtain a different look and feel, but in 8.1 there is a look and feel document that sets the skin and the skeleton, with the latter being the framework that is used to render the elements.

The look and feel file used in 8.1 is an XML document with an .laf extension that defines the name, the skin to use, and the skeleton to use. This allows one skeleton to be used with multiple skins, or vice-versa, with the former being the most likely case. Creating or modifying the look and feel file in 8.1 involves working with XML directly as there is no visual editor provided.


WebLogic Portal 8.1 uses Cascading Stylesheets (CSS) to a greater extent than 7.0, with more tags and improved structure.

In WebLogic Portal 7.0, a single main.css file contains entries for portal, portlet, pages, and other elements using a single-level naming convention. Examples include .titlebar, .portletcontainer, .pageheader, and so on. Creating a new skin includes modifying the main.css file and setting the desired values for these tags.

In WebLogic Portal 8.1, multiple files are used for this task:

The naming convention in WebLogic Portal 8.1 is multi-level, providing more granularity and flexibility when using styles. Examples include bea-portal-book-primary-menu, bea-portal-window-titlebarcontainer, bea-portal-body-footer, and so on. As with WebLogic Portal 7.0, creating a new skin includes copying an existing skin and modifying the styles.


In WebLogic Portal 8.1, a file contains entries that define the paths to images, links, scripts, and so on. In most cases it will not be necessary to modify this file, but the option to do so provides increased flexibility for locating resources.


There are a few JavaScript functions that are used in WebLogic Portal 8.1 for popup menus, initialization, and so on. These can be modified on a per-skin basis, but it is recommended that application specific scripts be placed in separate files.


Skins in the new release use fewer application-specific images. These images can be modified when creating custom skins.


The skeletons used in WebLogic Portal 8.1 are roughly equivalent to the framework JSPs in WebLogic Portal 7.0, but the code, tags, and overall structure are quite different. There is no direct path to transfer WebLogic Portal 7.0 framework modifications to skeleton in WebLogic Portal 8.1, but a JSP developer should be able to do the conversion manually.


The JSPs in a skeleton directory use scriptlets and JSP tags to render the various elements of the portal. Files include body.jsp, book.jsp, popupmenu.jsp, and so on, which correspond to the portal elements. Modifications to these files can change the way that the elements are rendered as well as the way that they behave.


Layouts are similar to those in WebLogic Portal 7.0, but have added flexibility and functionality. The layouts are derived from three base types: grid, border, and flow. These format types place elements on a grid, at the center, north, south, east, or west, or in a horizontal or vertical flow, respectively.

Layout Definition

The layouts in WebLogic Portal 8.1 are defined in XML in the form of .layout files. These files specify the type of layout to use (grid/border/flow), the number of columns, the HTML to use for the tools, and naming. When creating a new layout it is easiest to start with an existing layout definition and modify it.

Group Portals

Group portal definitions are not upgraded: in WebLogic Portal 8.1, the corresponding mechanism is the Desktop, by which a bundle of portal components is presented to a specified audience.

Webflow Support and Limitations

Portlet Webflow files can be upgraded, and can be used in conjunction with Page Flows.

WebLogic Workshop allows Webflow support to be added to existing WebLogic Portal 8.1 applications. This means Webflow portlets can run inside a WebLogic Portal 8.1. All Webflow presentation node types can be supported. An entire Webflow file can be supported, along with all its semantics, such as chaining.

Webflow and Page Flow portlets can be used in a common page. Page Flows can call Webflow files, allowing existing pipeline components and input processors to be leveraged. Page Flows can call out to Webflows and map the return to a forward in the Page Flow.


Page Flow JSPs cannot call validators. Webflow presentation nodes can be supported as long as they are the endpoint of a Webflow.

Page Flows

Provided they call the Webflow's entry point (using the syntax origin - namespace - event) Page Flows can call Webflow presentation nodes.

The resulting WebflowResponse can be used to construct a Java Page Flow Forward using the URI or URL constructors, but the processor nodes are definitely still in the loop.

Portal Services

Content from an existing WebLogic Portal 7.0 repository can be consumed and leveraged into any existing integration or process. The WebLogic Portal 8.1 Virtual Content Repository allows the content management administration tools to be used against content in a WebLogic Portal 7.0 repository. Additionally, a new bulkloader tool supports moving content from the flat WebLogic Portal 7.0 repository into WebLogic Portal 8.1 repositories, enabling you to take advantage of the new content management features.


WebLogic Portal 8.1 implements the WebLogic Server SSPI and uses the default LDAP store for user information.

Commerce and Personalization

The only significant change to commerce functionality is that the JSP tools for orders, payments and catalog are no longer included in the WebLogic Administration Portal.

Note: For instructions on adding Catalog Administration tools to an out-of-the-box WebLogic Portal 8.1 application, consult the "Adding Catalog Administration" section in Procedure for Upgrading from Compatibility on page 3-2.

Regarding personalization, property set schema and values remain unchanged and require no upgrade.

Behavior tracking requires current data be archived and re-hosted in a new schema. The procedure is outlined in Step 6: Upgrading Existing Behavior Tracking Data on page 3-14.


Some customers might have existing Struts-based applications or desire to start developing Struts applications on WebLogic Portal 7.0 because of the move to Page Flows in the WebLogic Portal 8.1 release, which are built on Struts 1.1. Guidelines on hosting Struts-based applications in WebLogic Portal 8.1 are listed in Struts Support.


How to Upgrade Existing Applications

When considering the route to run your WebLogic Portal 7.0 SP2 applications on WebLogic Portal 8.1, two choices are available immediately: to host the application to run in a Portal Compatibility Domain, as explained in Hosting 7.0 Applications in 8.1 Compatibility Domain on page 2-1, or to upgrade the application to run in WebLogic Portal 8.1, as explained in Upgrading from Compatibility Mode to WebLogic Portal 8.1 on page 3-1. The bulk of this guide is devoted to the Portal Compatibility Domain path, but also includes significant information required for re-implementation with WebLogic Portal 8.1.

Compatibility Domain

An existing Weblogic Portal 7.0 application can be converted to run in a Portal Compatibility Domain using the procedure detailed in Hosting 7.0 Applications in 8.1 Compatibility Domain on page 2-1.

Figure 1-1 Upgrade to Compatibility Domain

Upgrade to Compatibility Domain


Upgrading to Weblogic Portal 8.1

Listing  includes the information required for re-implementing an existing Weblogic Portal 7.0 application to run in WebLogic Portal 8.1. The capabilities and limitations of this configuration are explained here, along with a general description of new platform features included in WebLogic Portal 8.1.

Figure 1-2 Re-Implementation for WebLogic Portal 8.1

Re-Implementation for WebLogic Portal 8.1


Conversion of Portal and Portlet Definition Files

WebLogic Portal 8.1 includes the command line tool upradePortalFiles.cmd (.sh) that converts .portal and .portlet files from version 7.0 SP2 to version 8.1. This file resides in the WL_HOME\portal\upgrade directory. For more information, see Step 4: Upgrade Portal and Portlet Files on page 3-9.

Portal Web Applications

Portal Web applications built on WebLogic Portal 7.0 SP2 can be run on WebLogic Portal 8.1, using the upgrade procedure contained in Upgrading from Compatibility Mode to WebLogic Portal 8.1 on page 3-1.

Look and Feel Components

WebLogic Portal 7.0 skins and UI components can be re-hosted to Look and Feels and appropriate components in the WebLogic Portal Version 8.1. For details on Look and Feel implementation, see Connecting to an Active Directory Server on page E-3.


Skip navigation bar  Back to Top Previous Next