Skip navigation.

eDocs Home > BEA WebLogic Portal 8.1 Documentation > Upgrade Guide > Version 8.1 Compatibility Domain

Upgrade Guide

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

Version 8.1 Compatibility Domain

 

Hosting 7.0 Applications in 8.1 Compatibility Domain

WebLogic Portal 8.1, through Service Pack 2, supports a Compatibility Domain to enable upgraded WebLogic Portal 7.0 portal applications to be hosted on the newer version of the product. This section includes instructions on creating a Compatibility Domain, as well as steps required to upgrade your existing portal application to run in such a domain.

Note: The WebLogic Portal 8.1 Compatibility Domain originally supported applications built on WebLogic Portal 7.0 SP2. The WebLogic Portal 8.1 SP2 Compatibility Domain supports applications built on WebLogic Portal 7.0 SP4. The WebLogic Portal 8.1 Compatibility Domain is supported only through Service Pack 2.

Compatibility Explained

The 8.1 release of WebLogic Platform introduces significant changes to the platform in which Portal applications run. To ease the transition from WebLogic Portal 7.0 to 8.1, the Compatibility Domain enables 7.0 portal applications to be run on the new platform with minimal alterations.

The Compatibility Domain is a feature introduced in WebLogic Portal 8.1 in which an existing 7.x portal (and domain), possibly in a cluster, with existing data in the database, can be 'upgraded' to run in a specially-configured Compatibility Domain. This allows you to take advantage of the new platform features in new applications while also running existing applications within the same instance of WebLogic Platform.

 

Features and Limitations of the Compatibility Domain

This section explains features and limitations in a Compatibility Domain for the purpose of upgrade planning and strategy.

Generally speaking, portals built in WebLogic Portal 7.0 which are re-hosted to run in a Portal Compatibility Domain can be administered using the Weblogic 8.1 Administration Portal. No WebLogic Portal 8.1 features are supported in a portal enterprise application running in a Portal Compatibility Domain. Development tools such as the E-Business Control Center, WebLogic Workshop (any version) are not supported against applications running in a Portal Compatibility Domain.

Development Issues

This section includes some considerations that might affect your upgrade planning, depending on how your applications are implemented.

XA - Transaction Level Support

In the Compatibility Domain, the com.bea.p13n.util.jdbc.SequencerFactory is not backward compatible. In order to support XA, the sequencer must have its own datasource. So all the APIs where you could pass one in have been removed. The Framework File Reference on page E-14 includes information meant to assist in refactoring existing code. You can also consult the Javadoc at the following link:

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

MBean Configuration Mechanism

In WebLogic Portal 7.0, the portal MBeans (mail service, campaign service, ad service, behavior tracking, events, caches, etc.) were configured in the WebLogic Server console. A portal plug-in for the server console allowed you to change these settings.

In Portal Compatibility Mode, this portal plug-in is not present. In WebLogic Portal 8.1, these settings are exposed in the Portal Administration Tools, which do not run against an application in a Portal Compatibility Domain.

The solution is to edit the application-config.xml file (in the APP/META-INF directory), change the settings, then re-start the server.

Runtime and Administrative Issues

This section explains issues concerning running and administering applications in a Portal Compatibility Domain, and discusses differences between WebLogic Portal 7.0 and 8.1 applications.

Portal Compatibility Domain supports all runtime features of WebLogic Portal 7.0 with the following exceptions:

The Compatibility Domain supports a slightly limited security model: WebLogic Portal 7.0 portals work with users and groups in both the RDBMS and LDAP realms (with a single provider) and those in fileRealm.properties. A WebLogic 8.1 Portal Domain supports users in a single provider (RDBMS or LDAP). The net difference is that the fileRealm users and groups will no longer be automatically available in a Portal Compatibility Domain. These are typically system users and groups.

Listing Parent Groups

In Portal Compatibility Domain, the WebLogic Administration Portal does not list parent groups to which a user belongs, a change from WebLogic Portal 7.0. If groups A and B were subgroups of C, and a user were a member of A and B, the User Details screen would list all three groups in WebLogic Portal 7.0 Administration Portal, but only groups A and B in the Portal Compatibility Domain Administration Portal.

 

Authentication Providers in Portal Compatibility Domain

This section explains authentication considerations that might arise when creating new portals meant to run inside a Portal Compatibility Domain.

User and Group Management

Due to the design of WebLogic Portal 8.1, Portal User and Group Management can work with a single Security Authentication Provider (the first one listed in the console). This is a domain-level configuration—all Portal enterprise applications (more specifically, User and Group Management calls by the portal applications) in the domain can see only users and groups in the first Security Authentication Provider.

Default WebLogic Portal 8.1 domains are configured to use the default authentication provider (LDAP). By default, portals use LDAP to store and access users and groups.

A Portal Compatibility Domain uses the RDBMSAuthenticationProvider to provide access to the users and groups from the WebLogic 7.0 SP2 domain, because generally these were stored in the database. Therefore, portals running in a Portal Compatibility Domain will generally use RDBMS to store and access users and groups.

If the out-of-the-box WebLogic Portal 8.1 domain and the Portal Compatibility Domain use different authentication providers, there are two choices:

Note: If the WebLogic 7.0 SP2 domain uses LDAP instead of RDBMS authentication for users and groups, the Portal Compatibility domain will likewise use LDAP, meaning it will use the same provider as the out-of-the-box WebLogic Portal 8.1 domain.

To avoid this issue, any new portals designed in an out-of-the-box WebLogic Portal 8.1 domain should be configured to use RDBMSAuthenticationProvider.

This method requires installing the RDBMSAuthenticationProvider and designating it as the first provider in the list in the console, directly following the creation of the new domain.

 

Procedure for Hosting in Compatibility

The process for hosting an existing WebLogic Portal 7.0 application to run inside a Portal Compatibility Domain includes three phases:

  1. Creating a Portal Compatibility Domain
  2. Upgrading the Enterprise Application
  3. Final Adjustments to the Domain

Note: This procedure is based on the following assumptions:

The compatibility domain is called portalCompatibilityDomain and is created at user_projects\domains\portalCompatibilityDomain.

The "upgraded to compatibility" portal applications directory is user_projects\applications\... (the apps can be stored anywhere)

Creating a Portal Compatibility Domain

This section explains the steps necessary to create a Portal Compatibility Domain.

Before You Begin

This procedure requires that the following elements be in place:

Portal Compatibility starts with the portal domain configured using the portal Configuration Wizard template, and continues with a manual process for configuring the domain and 7x enterprise applications. A primary goal is that very few code changes will be required for a domain/ent-app that uses only Portal. Most of the configuration steps involve replacing .jar files and editing configuration files.

Discover SystemAdministrator Users from Existing Domain

Start the WebLogic Portal 7.0 server, open the Portal Administration Tools, and make a list of the users in the SystemAdministrator group. You will need this when upgrading the domain.

Back Up Existing Domain

Make backup copies of the existing domain, enterprise applications, and of course, the database.

Step 1: Create New Portal Domain

Use the Configuration Wizard in WebLogic Portal 8.1 to create a new Portal domain, using the Express setup option and the template for the Basic WebLogic Portal Domain. Use the same domain username and password as you used for the existing WebLogic Portal 7.0 domain.

Note: This procedure illustrates a domain called "portalCompatibilityDomain", but it can be named anything.

  1. Copy the dmsBase directory from the WebLogic Portal 7.0 domain directory to the Portal Compatibility Domain directory.
  2. Transfer commerce properties.
    1. If you were using commerce features in the WebLogic Portal 7.0 domain, copy the weblogiccommerce.properties file from the weblogic700\portal\ directory to the weblogic81\portal\ directory.
    2. Next, modify the compatibility domain's startWeblogic script to reference this newly copied properties file.

      3. For example, add the following line to the script:

      -Dcommerce.properties=<absolute path to weblogiccommerce.properties>

Step 2: Edit Start Script

Make the following edits to the startWeblogic.cmd script for the new WebLogic Portal 8.1 Compatibility Domain:

Step 3: Configure the New Domain

Edit the following settings for the new domain:

Step 4: Configure the Database

The upgrade process requires that the new domain have access to the existing database. Database settings are contained in files within the domain directory for both 7.0 and 8.1. The following steps ensure that the database settings in the new 8.1 domain match those in the existing 7.0 domain.

  1. Set the JDBCConnectionPool entry.

    2. Configure the <JDBCConnectionPool> URL settings in the 8.1 Portal Compatibility Domain's config.xml file to correspond to the URL settings in the config.xml file for the existing WebLogic Portal 7.0 domain, matching the database host, port, and schema name. Listings 2-1 and 2-2 show sample JDBCConnectionPool entries for a new WebLogic Portal 8.1 Compatibility Domain.

Listing 2-1 JDBCConnectionPool Entry for PointBase

<JDBCConnectionPool Name="cgPool" Targets="portalServer" 
CapacityIncrement="1" 
DriverName="com.pointbase.jdbc.jdbcUniversalDriver" 
InitialCapacity="5" MaxCapacity="50" 
Password="{3DES}dYceZKN2mwcfajtJC6uzSg==" 
Properties="user=weblogic;" RefreshMinutes="0" 
ShrinkPeriodMinutes="15" ShrinkingEnabled="true" 
SupportsLocalTransaction="true" TestConnectionsOnRelease="false" 
TestConnectionsOnReserve="false" URL="jdbc:pointbase:server://localhost:9092/wlportal"/>
<JDBCDataSource JNDIName="weblogic.jdbc.pool.commercePool" 
Name="commercePool" PoolName="cgPool" Targets="portalServer"/>

Listing 2-2 JDBCConnectionPool Entry for Oracle

<JDBCConnectionPool CapacityIncrement="1" 
DriverName="oracle.jdbc.driver.OracleDriver" 
InitialCapacity="25" MaxCapacity="25" Name="cgPool" 
Password="weblogic" 
Properties="user=weblogic" 
RefreshMinutes="0" ShrinkingEnabled="false" 
Targets="portalServer" TestConnectionsOnReserve="false" 
URL="jdbc:oracle:thin:@<dbhost>:1521:<dbSID>"/> 
<JDBCDataSource JNDIName="weblogic.jdbc.pool.commercePool" 
Name="commercePool" PoolName="cgPool" Targets="portalServer"/>

Note: A JDBC datasource has been added to Listing 2-2 for access to the WebLogic Portal 7.0 data.

  1. Update the database configuration files.

    2. Update Portal Compatibility Domain files to reference correct database configuration settings:

    Configure the 8.1 Portal Compatibility Domain's db_settings.properties file to correspond to the settings in the db_settings.properties file for the existing WebLogic Portal 7.0 domain, matching the host, db_name, port, dblogin, dbpassword, and connection fields. Listings 2-3 and 2-4 show sample configuration settings for a new WebLogic Portal 8.1 Compatibility Domain.

Listing 2-3 Database Configuration Entry for PointBase

#@IF_USING_POINTBASE@
database=POINTBASE
db_version=44
jdbcdriver=com.pointbase.jdbc.jdbcUniversalDriver
host=localhost
db_name=portal
port=9093
dblogin=WEBLOGIC
dbpassword=WEBLOGIC
connection=jdbc:pointbase:server://localhost:9093/wlportal
pointbase_ini=pointbase/pointbase.ini
#@ENDIF_USING_POINTBASE@

Listing 2-4 Database Configuration Settings for Oracle

database=ORACLE_THIN 
db_version=817 
jdbcdriver=oracle.jdbc.driver.OracleDriver 
server=<dbSID>
port=1521 
dblogin=USERNAMEGOESHERE 
dbpassword=PASSWORDGOESHERE 
connection=jdbc:oracle:thin:<dbHost>:1521:<dbSID>
  1. Prepare PointBase files for the schema upgrade.

    2. The PointBase instance requires a few preparatory steps before the schema upgrade:

    Follow the steps in Step 1: Upgrade PointBase Triggers on page 3-7. These steps prepare the PointBase files in upgrade/pointbase to be schema-upgraded.

  2. Upgrade the database schema.

    3. Before the actual data can be migrated from the existing database, the schema must be updated. This applies to all databases, which require the preparatory steps described in Step 2: Upgrade WebLogic Portal 7.0 Schema on page 3-8.

Upgrade Existing Data

This step updates the contents of the ENTITLEMENT_RULESET table.

All Databases

Follow the steps in Step 5: Upgrade ENTITLEMENT_RULESET Records on page 3-13.

Specifically, the following changes occur in this procedure:

For each row in the ENTITLEMENT_RULESET table, this modifies the value of the RULESET_DOCUMENT column as follows: The XML text http://www.bea.com/servers/p13n/xsd/rules/core/2.1.1 rules-core-2_1_1.xsd is prepended to the <cr:rule-set> element's xsi:schemaLocation attribute value.

PointBase Only

For PointBase only, copy the upgraded .wal and .dbn files from the upgrade/pointbase/ directory to the WebLogic Portal 8.1 Compatibility Domain directory (or wherever your .wal/.dbn files are).

Security Upgrade

The remainder of the steps required to prepare the new Portal Compatibility Domain involve upgrading security. The following tasks are described in this section:

Install and Configure the RDBMS Authentication Provider

The RDBMS authentication provider allows users and groups stored in a WebLogic Portal 7.0-based RDBMS store to be accessed from a portal in release 8.1 using the WebLogic Security Service Provider Interface (SSPI). This allows the WebLogic 8.1 Portal to work with users and groups defined in WebLogic Portal 7.0's RDBMSRealm, with minimal changes.

You can skip Step1 and Step2 below if your 7.0 domain did not use the RDBMSRealm. If you do not know whether you used the RDBMSRealm, open the config.xml file in the WebLogic Portal 7.0 domain. If the file does not contain a stanza for <RDBMSRealm>, then your 7.0 domain did not use the RDBMSRealm and you can skip to Step 3: Add PortalSystemAdministrators Group Using Outside Authentication Store. If config.xml does contain this stanza, check the value of BasicRealm in the <CachingRealm> stanza; if it matches the Name in the <RDBMSRealm>, then your 7.0 domain did use the RDBMSRealm and you must complete Step1 and Step 2 in this section.

Step 1: Configure the Authentication Provider

Use this procedure to configure the authentication provider in the new Compatibility Domain:

  1. In the new WebLogic Portal 8.1 Compatibility Domain, run the startWeblogic script and navigate to the following URL in the browser: http://localhost:7501/console. You might need to adjust the host name and port to match the settings in config.xml.
  2. Login with a user ID of weblogic and a password of weblogic. Choose Security—>Realms—>myrealm—>Providers and select Authentication.
  3. Click Configure a new RDBMSAuthenticator, then set the control flag to SUFFICIENT, and click Create.
  4. Click the Details tab and edit the database settings according to the config.xml and db_settings.properties in the previous section.

    5. For example, using sampleportal with PointBase, the settings would be as shown in Listing 2-5; using sampleportal with Oracle, the settings would be as shown in Listing 2-6.

  5. Click Apply.
  6. Choose Security—>Realms—>myrealm—>Providers and select Authentication.
  7. Select DefaultAuthenticator (the LDAP provider), set the control flag to SUFFICIENT, and click Apply.
  8. Select Security—>Realms—>myrealm—>Providers and select Authentication.
  9. Click Re-order the Configured Authentication Providers, make the RDBMSAuthenticator appear first in the list, and click Apply.
  10. Shut down the server.

Listing 2-5 Authentication Settings for PointBase

Database Driver: com.pointbase.jdbc.jdbcUniversalDriver 
Database URL: jdbc:pointbase:server://localhost:9092/wlportal 
Schema Properties: user=WEBLOGIC;password=WEBLOGIC;server=jdbc:pointbase:server://localhost:9092/wlportal 
Minimum Password Length: whatever it was in 7.x (ie 1 character for 7x sampleportal)

Listing 2-6 Authentication Settings for Oracle

Database Driver: oracle.jdbc.driver.OracleDriver 
Database URL: jdbc:oracle:thin:@myOraDB:1521:myOraInstance 
Database Username: weblogic
Database Password: weblogic
Schema Properties: user=weblogic;password=weblogic
Minimum Password Length: 8

Step 2: Add PortalSystemAdministrators Group Using RDBMSAuthentication

This section is applicable only if your 7.0 domain used the RDBMSRealm.

In order to support using the WebLogic Portal 7.0 Administration Tools, you must add the PortalSystemAdministrators group to the RDBMSAuthenticationProvider. If users and groups were stored in the database in the existing WebLogic Portal 7.0 domain, you must add the PortalSystemAdministrators group to RDBMSAuthentication.

Using the SQL editor of your choice (for example, SQL*Plus or PointBase Console), run the following SQL: 

insert into GROUP_SECURITY( GROUP_ID, GROUP_NAME ) values ( 900, 'PortalSystemAdministrators' ); 
insert into ENTITY( ENTITY_ID, ENTITY_NAME, ENTITY_TYPE ) values ( 900, 'PortalSystemAdministrators', 'Group' );

Note: 900 is a reserved number in this index, so there should be no problem with this operation.

Step 3: Add PortalSystemAdministrators Group Using Outside Authentication Store

This step is applicable only if your 7.0 domain did not use the RDBMSRealm.

If users and groups were not stored in the database in the existing WebLogic Portal 7.0 domain, add the PortalSystemAdministrators group to the LDAP (or other) store.

You might want to migrate any ACLs in the fileRealm.properties file of the existing WebLogic Portal 7.0 domain.

Upgrading the Enterprise Application

This section describes how to configure a WebLogic Portal 7.0 enterprise application to run in the WebLogic Portal 8.1 Compatibility Domain that you created by following the instructions in the Creating a Portal Compatibility Domain section.

In the next section, ENT-APP refers to the directory for your enterprise application, and WEB-APP refers to the directory for your web application(s).

Before You Begin

This section includes instructions for re-hosting enterprise applications to run in the new WebLogic Portal 8.1 Compatibility Domain. Make sure you have performed the backup steps described in the Before You Begin section of Creating a Portal Compatibility Domain on page 2-5.

For sampleportal only:

  1. Make sure the values in the db_settings.properties file in your 7.0 domain directory are consistent with those in your 8.1 Compatibility Domain. If you have changed your 8.1 settings to match the 7.0 settings, you can skip the remaining steps in this section.
  2. Run configca.bat/.sh from your 7.0 domain directory. This creates an updated version of BlackBoxNoTx.rar in your 7.0 enterprise application directory.
  3. Copy BlackBoxNoTx.rar from your enterprise application directory to the customerservice portlet directory. For example:

cp\bea70\weblogic700\samples\portal\sampleportalDomain\beaApps\
sampleportal\BlackBoxNoTx.rar\bea70\weblogic700\samples\portal\
sampleportalDomain\beaApps\sampleportal\sampleportal\portlets\
customerservice

Procedure for Each Enterprise Application

For each enterprise application to be upgraded for the new domain, follow these steps:

  1. Copy the enterprise application directory from the existing WebLogic Portal 7.0 domain to the WebLogic Portal 8.1 Compatibility Domain.
  2. Delete the following objects:
  1. Create Enterprise Application Directory with the following hierarchy:
    <ENT-APP dir name>\APP-INF\lib.

    For example, if you were upgrading sampleportal you would create
    WL_HOME\samples\portal\applications\sampleportal\APP-INF\lib.
  2. Copy the following files from the <bea81>\weblogic81 directory to your new APP-INF\lib directory
  1. Copy the following files from the <bea81>\weblogic81 directory to your <ENT-APP dir_name> directory:
  1. Make the following changes in the <ENT-APP>/<WEB-APP>/WEB-INF/lib directory for each of the web applications in your enterprise application:
  1. Make the following changes in the application.xml file in the <ENT-APP>/META-INF/ directory:

Note: Replace the <web-uri>, not the <context-root>.

  1. Make the following changes in the application-config.xml file in the <ENT-APP>/META-INF/ directory:

Listing 2-7 DocumentConnectionPool Entry

<ContentManagement Name="ContentManagement"> 
<ContentStore Name="adapter" ClassName="com.bea.p13n.content.adapter.RepositoryImpl" 
Properties="CONTENT_MANAGER_HOME=${APPNAME}.BEA_personalization.DocumentManager" /> 
</ContentManagement> 
<CommercePipelineComponentSupport 
JdbcPoolName="weblogic.jdbc.jts.commercePool" />

Content Management Configuration

The SamplePortal application provided with WebLogic Portal 7.0 uses a custom Document Provider Interface (DPI) integration for content management. If the enterprise application you are upgrading also uses such an integration, this generally implies that you have one or more JSPs using code similar to that shown in Listing 2-8. If this is the case, perform the steps in Step 1: Change the Content Management application-config.xml File.

Listing 2-8 Custom Content Management JSP Code

<pz:contentSelector ... contentHome="java:comp/env/ejb/NewsletterManager"  <-- NOTE this is not the standard value of "<%=ContentHelper.DEF_DOCUMENT_MANAGER_HOME%>" />

Step 1: Change the Content Management application-config.xml File

Make the following modifications to support this Content Management feature:

  1. For each additional document provider, add a <ContentStore> section to the <ContentManagement> node. The <jndi-name> for the document provider can be found in weblogic-ejb-jar.xml. For sampleportal, the entry is as follows:
<jndi-name>${APPNAME}.BEA_portal_examples.NewsletterDocumentManager</jndi-name>
  1. Set the CONTENT_MANAGER_HOME property of the <ContentStore> to be the JNDI name used to look up the documentprovider. For the sampleportal, the entry is as follows: 
Properties="CONTENT_MANAGER_HOME=${APPNAME}.BEA_portal_examples.NewsletterDocumentManager"

For sampleportal, add this as a second <ContentManagement> element, as shown in Listing 2-9:

Listing 2-9 The second <ContentManagement> element for sampleportal

<ContentStore 
Name="newsletters" 
ClassName="com.bea.p13n.content.adapter.RepositoryImpl" 
Properties="CONTENT_MANAGER_HOME=${APPNAME}.BEA_portal_examples.NewsletterDocumentManager" />

Step 2: Edit the web.xml File

For each web application, make the following change to the web.xml file in the <ENT-APP>/<WEB-APP>/WEB-INF/ directory:

Replace the code in Listing 2-10 with that in Listing 2-11.

Listing 2-10 pz_taglib.jar reference

<taglib> 
<taglib-uri>pz.tld</taglib-uri> 
<taglib-location>/WEB-INF/lib/pz_taglib.jar</taglib-location> 
</taglib>

Listing 2-11 pz_compat_taglib.jar reference

<taglib> 
<taglib-uri>pz.tld</taglib-uri> 
<taglib-location>/WEB-INF/lib/pz_compat_taglib.jar</taglib-location> 
</taglib>

Step 3: Edit the config.xml File

This section lists two modifications to the config.xml file; one for commerce support, the other for every enterprise application.

If the enterprise application uses commerce features, edit the config.xml file, inserting the following StartupClass section above any application listings, and setting the Target to the servername, as shown in Listing 2-12.

Listing 2-12 StartupClass Entry for Commerce Support

<StartupClass 
ClassName="com.beasys.commerce.ebusiness.security.KeyBootstrap" 
LoadBeforeAppActivation="true" 
FailureIsFatal="false" 
Name="Commerce KeyBootstrap" 
Targets="portalServer"/>

Add a reference to the enterprise application(s), complete with the correct path. Examples using sample applications that shipped with WebLogic Portal 7.0 are shown in Listing 2-13, Listing 2-14, Listing 2-15, and Listing 2-16.

The following notes apply to Listing 2-13, Listing 2-14, Listing 2-15, and Listing 2-16:

Listing 2-13 SAMPLEPORTAL config.xml File

<Application Deployed="true" Name="sampleportal" 
Path="D:\bea81\weblogic81\samples\portal\sampleportal" TwoPhase="true"> 
<ApplicationConfiguration Name="sampleportal" 
Targets="portalServer" URI="META-INF/application-config.xml"/> 
<ConnectorComponent Name="BlackBoxNoTx" Targets="portalServer" URI="BlackBoxNoTx.rar"/> 
<EJBComponent Name="commerce" Targets="portalServer" URI="commerce.jar"/> 
<EJBComponent Name="p13n_ejb" Targets="portalServer" URI="p13n_ejb.jar"/> 
<EJBComponent Name="portal" Targets="portalServer" URI="portal.jar"/> 
<!-- <EJBComponent Name="sampleportal" Targets="portalServer" URI="sampleportal.jar"/>  --> 
<EJBComponent Name="wps" Targets="portalServer" URI="wps.jar"/> 
<EJBComponent Name="pipeline" Targets="portalServer" URI="pipeline.jar"/> 
<EJBComponent Name="portalmanager" Targets="portalServer" URI="netuix.jar"/> 
<EJBComponent Name="prefs" Targets="portalServer" URI="prefs.jar"/> 
<EJBComponent Name="content" Targets="portalServer" URI="content.jar"/> 
<EJBComponent Name="contentrepo" Targets="portalServer" URI="content_repo.jar"/> 
<WebAppComponent Name="datasync" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="datasync.war"/> 
<WebAppComponent Name="defaultWebApp" 
ServletReloadCheckSecs="300" Targets="portalServer" URI="defaultWebApp"/> 
<WebAppComponent Name="sampleportal" 
ServletReloadCheckSecs="300" Targets="portalServer" URI="sampleportal"/> 
<WebAppComponent Name="toolSupport" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="toolSupport.war"/> 
<WebAppComponent Name="tools" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="tools700.war"/> 
</Application>
	<Application Deployed="true" Name="wlpDocsApp" 
Path="D:\bea81\weblogic81\portal\lib" 
StagedTargets="portalServer" TwoPhase="true"> 
<WebAppComponent IndexDirectoryEnabled="false" Name="wlpDocs" 
ServletReloadCheckSecs="300" Targets="portalServer" URI="wlpDocs.war"/> 
</Application>

Listing 2-14 P13NApp config.xml File

<Application Deployed="true" Name="p13nApp" 
Path="D:\weblogic81\samples\portal\p13nApp" TwoPhase="true"> 
<ApplicationConfiguration Name="p13nApp" Targets="portalServer" URI="META-INF/application-config.xml"/> 
<EJBComponent Name="commerce" Targets="portalServer" URI="commerce.jar"/> 
<EJBComponent Name="p13n_ejb" Targets="portalServer" URI="p13n_ejb.jar"/> 
<EJBComponent Name="wps" Targets="portalServer" URI="wps.jar"/> 
<EJBComponent Name="pipeline" Targets="portalServer" URI="pipeline.jar"/> 
<EJBComponent Name="portalmanager" Targets="portalServer" URI="netuix.jar"/> 
<EJBComponent Name="prefs" Targets="portalServer" URI="prefs.jar"/> 
<EJBComponent Name="content" Targets="portalServer" URI="content.jar"/> 
<EJBComponent Name="contentrepo" Targets="portalServer" URI="content_repo.jar"/> 
<WebAppComponent Name="datasync" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="datasync.war"/> 
<WebAppComponent Name="defaultWebApp" 
ServletReloadCheckSecs="300" Targets="portalServer" URI="defaultWebApp"/> 
<WebAppComponent Name="p13n" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="p13n"/> 
<WebAppComponent Name="toolSupport" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="toolSupport.war"/> 
<WebAppComponent Name="tools" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="tools700.war"/> 
</Application> 
<Application Deployed="true" Name="wlpDocsApp" 
Path="D:\weblogic81\portal\lib" 
StagedTargets="portalServer" TwoPhase="true"> 
<WebAppComponent IndexDirectoryEnabled="false" Name="wlpDocs" 
ServletReloadCheckSecs="300" Targets="portalServer" URI="wlpDocs.war"/> 
</Application>

Listing 2-15 WLCSApp config.xml File

<Application Deployed="true" Name="wlcsApp" 
Path="D:\weblogic81\samples\portal\wlcsApp" TwoPhase="true"> 
<ApplicationConfiguration Name="wlcsApp" Targets="portalServer" URI="META-INF/application-config.xml"/> 
<EJBComponent Name="commerce" Targets="portalServer" URI="commerce.jar"/> 
<EJBComponent Name="p13n_ejb" Targets="portalServer" URI="p13n_ejb.jar"/> 
<!-- <EJBComponent Name="wlcsSample" Targets="portalServer" URI="wlcsSample.jar"/> --> 
<EJBComponent Name="wps" Targets="portalServer" URI="wps.jar"/> 
<EJBComponent Name="pipeline" Targets="portalServer" URI="pipeline.jar"/> 
<EJBComponent Name="portalmanager" Targets="portalServer" URI="netuix.jar"/> 
<EJBComponent Name="prefs" Targets="portalServer" URI="prefs.jar"/> 
<EJBComponent Name="content" Targets="portalServer" URI="content.jar"/> 
<EJBComponent Name="contentrepo" Targets="portalServer" URI="content_repo.jar"/> 
<WebAppComponent Name="datasync" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="datasync.war"/> 
<WebAppComponent Name="defaultWebApp" 
ServletReloadCheckSecs="300" Targets="portalServer" URI="defaultWebApp"/> 
<WebAppComponent Name="wlcs" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="wlcs"/> 
<WebAppComponent Name="toolSupport" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="toolSupport.war"/> 
<WebAppComponent Name="tools" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="tools700.war"/> </Application> 
<Application Deployed="true" Name="wlpDocsApp" 
Path="D:\weblogic81\portal\lib" 
StagedTargets="portalServer" TwoPhase="true"> 
<WebAppComponent IndexDirectoryEnabled="false" Name="wlpDocs" 
ServletReloadCheckSecs="300" Targets="portalServer" URI="wlpDocs.war"/> 
</Application>

Listing 2-16 StockPortal config.xml File

<Application Deployed="true" Name="stockportal" 
Path="D:\weblogic81\samples\portal\portal" TwoPhase="true"> 
<ApplicationConfiguration Name="portal" Targets="portalServer" URI="META-INF/application-config.xml"/> 
<EJBComponent Name="commerce" Targets="portalServer" URI="commerce.jar"/> 
<EJBComponent Name="p13n_ejb" Targets="portalServer" URI="p13n_ejb.jar"/> 
<!--        <EJBComponent Name="stockportal" Targets="portalServer" URI="stockportal.jar"/> --> 
<EJBComponent Name="portal" Targets="portalServer" URI="portal.jar"/> 
<EJBComponent Name="wps" Targets="portalServer" URI="wps.jar"/> 
<EJBComponent Name="pipeline" Targets="portalServer" URI="pipeline.jar"/> 
<EJBComponent Name="portalmanager" Targets="portalServer" URI="netuix.jar"/> 
<EJBComponent Name="prefs" Targets="portalServer" URI="prefs.jar"/> 
<EJBComponent Name="content" Targets="portalServer" URI="content.jar"/> 
<EJBComponent Name="contentrepo" Targets="portalServer" URI="content_repo.jar"/> 
<WebAppComponent Name="datasync" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="datasync.war"/> 
<WebAppComponent Name="defaultWebApp" 
ServletReloadCheckSecs="300" Targets="portalServer" URI="defaultWebApp"/> 
<WebAppComponent Name="stockportal" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="stockportal"/> 
<WebAppComponent Name="toolSupport" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="toolSupport.war"/> 
<WebAppComponent Name="tools" ServletReloadCheckSecs="300" 
Targets="portalServer" URI="tools700.war"/> 
<WebAppComponent Name="workshop" ServletReloadCheckSecs="0" 
Targets="portalServer" URI="workshop"/> 
</Application>

Modify Code

Search the code from the existing WebLogic Portal 7.0 application for calls to the following class:

com.bea.p13n.util.jdbc.SequencerFactory createSequencer( String, DataSource) method. Any calls to this method must be updated as follows:

Replace the code in Listing 2-17 with that in Listing 2-18.

Listing 2-17 A Call to createSequencer Class: Before

sequencer = SequencerFactory.createSequencer("ORDER_LINE_ID_SEQUENCE", getDataSource());

Listing 2-18 A Call to createSequencer Class: After

sequencer = SequencerFactory.createSequencer( "ORDER_LINE_ID_SEQUENCE" );

Note: Exceptions are different, so you might also need to update any enclosing try/catch blocks.

Step 1: Upgrade Web Service Client Proxies

Find all web service proxy (client) code used by the enterprise application or by the Web application. Usually there is a .wsdl file, a *Codec.java or *_Stub.java.

This section uses concrete examples of steps taken to make the WLCSApp compliant with the new framework.

Step 2: Change Web Service Proxies

If you modified the web service proxies in the WebLogic Portal 7.0 domain, you need to do the same modifications in the new domain. In any case, the files will need to be re-generated because the generated proxy jar file code has changed.

Note: The proxy code needs to be in a separate jar in the APP-INF/lib directory to work at runtime. It will not work if you merely compile it and place it in wlcsSample.jar. Therefore, you must generate a proxy jar file, and then manually replace any changed proxy files.

Here is an example of a target that generates proxy jar files—add an entry such as that shown in Listing 2-19 to your build file.

Listing 2-19 Web Service Proxy Rewrite Entry

<target name="stubgen" > 
<property name="taxWsdlUrl"  
value="http://localhost:7501/taxws/TaxService?WSDL" /> 
<property name="payWsdlUrl"  
value="http://localhost:7501/payws/PaymentService?WSDL" /> 
<clientgen wsdl="${taxWsdlUrl}" packageName="examples.wlcs.sampleapp.tax" 
clientJar="taxwsproxy.jar" /> 
<clientgen wsdl="${payWsdlUrl}" packageName="examples.wlcs.sampleapp.payment" 
clientJar="paywsproxy.jar" /> 
</target>

Upgrade Application-Sync Files

Follow the "upgrade application-sync" steps in Step 3: Upgrade Application-Sync Files on page 3-9.

Final Adjustments to the Domain

This set of steps requires at least one enterprise application to be upgraded and deployed, because it requires the WebLogic 7.0 Portal Administration Tools.

Add Users to PortalSystemAdministrators Group

Add all members of the WebLogic 7.0 Portal SystemAdministrator group to the PortalSystemAdministrators group.

This procedure is explained using sampleportal.

  1. Launch the server in your 8.1 compatibility domain.
  2. Open Weblogic Portal Administration Tools at http://localhost:7501/sampleportalTools and login as weblogic/weblogic, or whatever system user ID and password you used to create the 8.1 compatibility domain.
  3. In User Management, under Groups, select PortalSystemAdministrators.
  4. Select the users in the WebLogic Portal 7.0 SystemAdministrator group, and add them to PortalSystemAdministrators.
  5. Log into the WebLogic Server Console, choose Security—>Realms—>myRealms—>Global Roles, and click Configure a New Global Role.
  1. Configure the new global role as described in Creating Global Roles, at:
    2. http://download.oracle.com/docs/cd/E13222_01/wls/docs81/secwlres/secroles.html#1219839
  2. Save the changes and shut down the server.

Upgrade CustomerRole in SSPI to Point to RDBMS Groups

If the existing WebLogic 7.0 domain contained an application that uses commerce, the CustomerRole security role must be associated with the wlcs_customer RDBMS group. This modification is necessary because normally the CustomerRole security role is associated with the wlcs_customer LDIFT group, and therefore won't perform correctly with members of the wlcs_customer RDBMS group.

Note: To perform this configuration, the assignment must be removed from the default LDIFT files. This means that if you delete the server directory (which includes LDAP information), you will need to do these steps again.

To associate the CustomerRole security role with the wlcs_customer RDBMS group, take the following steps:

  1. Edit the compatibility domain's DefaultRoleMapperInit.ldift file, deleting the following section: 
    2. dn: cn=::CustomerRole,ou=ERole,ou=@realm@,dc=@domain@ 
    objectclass: top 
    objectclass: ERole 
    cn: ::CustomerRole 
    EExpr:: Z3dsY3NfY3VzdG9tZXIK
  2. Edit the compatibility domain's security.xml file, deleting the following sections as shown in Listing 2-20 and Listing 2-21 below.

Listing 2-20 ns1:group Entry

<ns1:group name="wlcs_customer">
<ns1:roleMemberOf ref="CustomerRole"/> 
</ns1:group>

Listing 2-21 ns1:role Entry

<ns1:role name="CustomerRole" description="View/modify the wlcs customer settings"/>

  1. Delete the portalServer directory inside the compatibility domain. This directory is named <yourEnterpriseApplicationName>Server.
  2. Start the WebLogic Portal Server.
  3. Log into the WebLogic Server console, and click Configure a new global role.
  4. Name the new role CompatibilityCustomerRole, and click Apply.
  5. From the Conditions tab, select Caller is a member of the group and click Add.
  6. Enter group name wlcs_customer and click Add, OK, then Apply.
  7. Shut down the server.

Users and Groups Specified in fileRealm.properties

You must add any system-level users and groups, which under 7x were specified in fileRealm.properties, to the authentication provider used by WebLogic Portal 8.1.

Note: This step is not needed for sampleportal, wlcsApp, p13nApp, or stockportal.

Unlike WebLogic Portal 7.0, which allowed users and groups to be stored in both fileRealm (where system users and groups were stored) and the main store (where typical users and groups were stored), WebLogic Portal 8.1 works with users and groups in the single authentication provider.

Therefore, if you want to support system users and groups (weblogic, Operators, Monitors, and so on) in the portal, you will need to move these users over to the authentication provider. This applies to any system users or groups in the fileRealm to which you want to provide portal access and portal tool access in the new Portal Compatibility Domain.

 

Skip navigation bar  Back to Top Previous Next