Oracle® Fusion MiddlewareUpgrading Oracle WebLogic Server

14c (14.1.1.0.0)F18286-02June 2020

Oracle Fusion Middleware Upgrading Oracle WebLogic Server, 14c (14.1.1.0.0)

F18286-02

Copyright © 2007, 2020, Oracle and/or its affiliates.

This software and related documentation are provided under a license agreement containing restrictions onuse and disclosure and are protected by intellectual property laws. Except as expressly permitted in yourlicense agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license,transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverseengineering, disassembly, or decompilation of this software, unless required by law for interoperability, isprohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. Ifyou find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it onbehalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software,any programs embedded, installed or activated on delivered hardware, and modifications of such programs)and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Governmentend users are "commercial computer software" or “commercial computer software documentation” pursuantto the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such,the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works,and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programsembedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oraclecomputer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in thelicense contained in the applicable contract. The terms governing the U.S. Government’s use of Oracle cloudservices are defined by the applicable contract for such services. No other rights are granted to the U.S.Government.

This software or hardware is developed for general use in a variety of information management applications.It is not developed or intended for use in any inherently dangerous applications, including applications thatmay create a risk of personal injury. If you use this software or hardware in dangerous applications, then youshall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure itssafe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of thissoftware or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks oftheir respective owners.

Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks areused under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc,and the AMD logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registeredtrademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products,and services from third parties. Oracle Corporation and its affiliates are not responsible for and expresslydisclaim all warranties of any kind with respect to third-party content, products, and services unless otherwiseset forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will notbe responsible for any loss, costs, or damages incurred due to your access to or use of third-party content,products, or services, except as set forth in an applicable agreement between you and Oracle.

Contents

Preface

Documentation Accessibility vii

Conventions vii

1 Introduction

Version Compatibility 1-2

Important Terminology 1-2

Upgrading From a WebLogic Version Prior to WebLogic Server 10.3.6 1-3

Overview of the Upgrade Process 1-4

Before You Begin 1-5

Interoperability and Compatibility with Previous Releases 1-7

Patching an Existing WebLogic Server Installation 1-7

About Zero Downtime Patching 1-7

About Rolling Updates 1-8

Performing a Rolling Update 1-9

Rolling Back a Patch, Bundle Patch, or Patch Set Update 1-10

Obtaining a List of Applied Patches 1-10

2 Roadmap for Upgrading Your Application Environment

Plan for an Upgrade 2-1

Step 1: Inventory the Application Environment 2-1

Step 2: Verify Supported Configuration Information 2-2

Step 3: Review the Compatibility Information 2-3

Step 4: Create an Upgrade Plan 2-3

Prepare for the Upgrade 2-3

Step 1: Check Your Applications (Undeploy If Necessary) 2-4

Step 2: Shut Down Servers in the Application Environment 2-4

Step 3: Back Up the Application Environment 2-4

Step 4: Install Required Oracle Products 2-4

Step 5: Set Up the Environment 2-4

Upgrade Your Application Environment 2-5

iii

Procedure for Upgrading an Application Environment 2-7

What to Do If the Upgrade Process Fails 2-8

3 Reconfiguring WebLogic Domains

Before You Begin 3-1

Upgrading Domains Created Prior to WebLogic Server 10.3.0 3-1

Setting CONFIG_JVM_ARGS on UNIX and Linux Systems 3-2

Backing Up the Domain 3-2

Determining Node Manager Upgrade Procedure 3-2

Configuring Multiple Per Domain Node Managers on the Same Machine 3-3

Running Two Per Host Node Managers on the Same Machine 3-4

Reconfiguring a WebLogic Domain 3-4

Reconfiguring a WebLogic Domain in Graphical Mode 3-5

Reconfiguring a WebLogic Domain Using WebLogic Scripting Tool 3-7

Completing the Node Manager Configuration 3-9

Completing the Node Manager Configuration (Two Per Host Node Managers) 3-11

Updating a Managed Server Domain on a Remote Machine 3-12

Important Notes About the Domain Upgrade Process 3-14

Completing Post-Upgrade Tasks 3-15

Re-apply Customizations to Startup Scripts 3-15

Default Startup Scripts 3-15

Custom Startup Scripts 3-15

Verify File Permissions 3-16

Verify Remote Server Startup Options 3-16

Recreating the Windows Node Manager Service 3-17

Promote the Application Environment to Production 3-17

Enabling Edition-based Redefinition for Standalone WebLogic ServerInstallations (Optional) 3-17

Stop the WebLogic Server Domain 3-18

Create an Edition-enabled User and the Edition 3-18

Run the WebLogic Services Upgrade Scripts 3-19

Run the Create Table Scripts 3-20

Set the New Edition as the Default 3-20

Restart the WebLogic Server Domain 3-21

Upgrading a Domain that Uses an Evaluation Database 3-21

4 Upgrading WebLogic Web Services

Upgrading a 10.3.x RESTful Web Service (JAX-RS) to 12.2.x 4-1

Upgrading a 10.x WebLogic Web Service (JAX-WS) to 12.2.x 4-3

Upgrading an 8.1 WebLogic Web Service to the WebLogic JAX-WS Stack 4-3

iv

Upgrading a WebLogic JAX-RPC Web Service to the WebLogic JAX-WS Stack 4-4

A WebLogic Server 14.1.1.0.0 Compatibility with Previous Releases

Java EE 8 Support A-3

Compatibility Changes When Migrating From JDK 8 to JDK 11 A-3

Upgraded Version of Jython A-4

Removed WebLogic Server Multitenant Functionality and Resource ConsumptionManagement A-4

Removed WebLogic Full and IIOP-Based Clients A-5

Components and Features Removed in WebLogic Server 14.1.1.0.0 A-5

About WebLogic Server Cluster Messaging A-5

Upgraded Version of Apache Ant A-6

Removed the Option to Limit Run-Time Footprint When Starting WebLogic Server A-6

Random Number Generator A-7

Automatic Binding of the Default CommonJ Work Manager Has Been Removed A-7

Parallel Deployment A-8

Server Logging Bridge A-8

Oracle Database Drivers A-9

Oracle Enable JavaNet FastPath A-9

Maximum POST Size A-10

WLDF Schema Upgrade A-10

jdbc-connection-timeout-secs Element Has Been Removed A-10

Commitment of Local Transactions A-10

JVM Settings A-11

Setting the Location of Java Endorsed Directory for WebLogic Server A-11

Setting permgen space A-12

Node Manager startScriptEnabled Default Value A-13

Enterprise Java Beans (EJBs) A-13

WebLogic Server 8.1 Web Services Stack Has Been Removed A-13

Universal Description and Discover (UDDI) Registry Has Been Removed A-14

Certicom SSL Implementation Has Been Removed A-14

Oracle Coherence Version A-14

Deprecated and Obsolete Web Application Features A-14

Evaluation Database Changed From PointBase to Derby A-14

DataSource Profile Logging A-15

ONS Debugging A-15

Oracle Type 4 JDBC Drivers From DataDirect A-15

Default Message Mode Has Changed A-15

Modifications to SSLMBean A-15

New Web Services Features A-16

Introduction of JSSE A-16

v

Performance Enhancements for Security Policy Deployment A-17

ActiveCache A-17

Class Caching A-17

Deprecated JDBC Drivers A-17

Changes to weblogic.jms.extension API A-18

Persistent Store Updates A-18

Oracle Internet Directory and Oracle Virtual Directory Authentication Providers A-18

CapacityIncrement Attribute A-18

Middleware Home Directory A-19

Resource Registration Name A-19

Servlet Path Mapping A-19

Index

vi

Preface

This preface describes the document accessibility features and conventions used inthis guide—Upgrading Oracle WebLogic Server.

Documentation AccessibilityFor information about Oracle's commitment to accessibility, visit theOracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic supportthrough My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsif you are hearing impaired.

ConventionsThe following text conventions are used in this document:

Convention Meaning

boldface Boldface type indicates graphical user interface elements associatedwith an action, or terms defined in text or the glossary.

italic Italic type indicates book titles, emphasis, or placeholder variables forwhich you supply particular values.

monospace Monospace type indicates commands within a paragraph, URLs, codein examples, text that appears on the screen, or text that you enter.

vii

1Introduction

You can upgrade WebLogic servers and domains from an earlier version of WebLogicServer to WebLogic Server 14c (14.1.1.0.0). You can also update an existingapplication to run on Oracle WebLogic Server 14.1.1.0.0.

While upgrading to version 14.1.1.0.0, you might want to change your applicationor you might have to change the application. However, this document focuses onlyon issues that you should consider when moving an application to WebLogic Server14.1.1.0.0 without making any application changes.

The instructions in this document are for the following upgrade scenarios:

• Upgrading from any WebLogic Server 10.3.x release to WebLogic Server14.1.1.0.0

• Upgrading from WebLogic Server 12.1.x to WebLogic Server 14.1.1.0.0

Note:

If you are upgrading from a release prior to WebLogic Server 10.3.1, seeUpgrading From a WebLogic Version Prior to WebLogic Server 10.3.6.

If you are upgrading from version 12.2.1.1.0 and later to version 14.1.1.0.0,you do not need to run the Upgrade Assistant (UA) for schemas orconfiguration upgrades. You must only run the Reconfiguration Wizard.However, you must install the binaries in a new Oracle home and run thereconfiguration offline.

This document also describes how to update (reconfigure) an existing WebLogicServer 10.3.x, 12.1.x, or 12.2.1.x domain to be compatible with WebLogic Server14.1.1.0.0, as well as how to upgrade Web Services.

WebLogic Server generally supports high levels of upgrade capability acrossWebLogic Server versions. This document is intended to provide WebLogic Serverupgrade support and identify issues that may surface during an upgrade so that theycan be easily resolved.

1-1

Note:

For information about upgrading your Java EE environment and yourdeployed applications from Oracle Application Server 10g and OracleContainers for Java EE (OC4J) to WebLogic Server 14c (14.1.1.0.0), seeFusion Middleware Upgrade Guide for Java EE.

This document describes the upgrade process for Oracle productinstallations that include only WebLogic Server. If your installation includesother Oracle Fusion Middleware products, prior to beginning the upgrade,see Planning an Upgrade of Oracle Fusion Middleware and the upgradeguides for each Fusion Middleware product in your installation.

WebLogic Server 14.1.1.0.0 includes the Fusion Middleware Reconfiguration Wizardto assist you with upgrading WebLogic Server and your application environments.

Most WebLogic Server applications can be run without modifications in the newWebLogic Server 14.1.1.0.0 application environment.

This chapter includes the following sections:

• Version Compatibility

• Important Terminology

• Upgrading From a WebLogic Version Prior to WebLogic Server 10.3.6

• Overview of the Upgrade Process

• Before You Begin

• Interoperability and Compatibility with Previous Releases

• Patching an Existing WebLogic Server Installation

Version CompatibilityBefore you upgrade WebLogic Server, review the WebLogic Server and domaincompatibility requirements for WebLogic Server 14.1.1.0.0.

See Compatibility Within a Domain in Understanding Oracle WebLogic Server.

Within a WebLogic domain, the Administration Server, all Managed Server instances,and the WebLogic domain must be at the same WebLogic Server Major and MinorVersion. This means that in WebLogic Server 12.2.1.x, the Administration Server,Managed Servers, and the WebLogic domain must all be at version 12.2.1.x. Versionsof WebLogic Server prior to 12.1.2 have slightly different compatibility allowancesregarding specific WebLogic Server versions that are supported in a given domain.

Important TerminologyThe documentation for upgrading WebLogic Server uses various terms whendescribing its features and functionality. It is important that you have a goodunderstanding of these terms.

Chapter 1Version Compatibility

1-2

• Upgrade—In this document, the term upgrade refers to the process of upgradingWebLogic Server and moving an existing application, unchanged, to a new(upgraded) WebLogic Server version.

• Reconfiguration—The process of upgrading a domain that was created with aprevious WebLogic Server version so that it is compatible with the WebLogicServer version to which you have upgraded. This can be done using either theReconfiguration Wizard or WLST.

• Application Environment—An application environment includes applications andthe WebLogic domains in which they are deployed. It also includes any applicationdata associated with the domain, and may include resources such as databaseservers, firewalls, load balancers, and LDAP servers.

• Migrate—To move an application or domain configuration from a third-partyproduct to an Oracle product.

• Interoperability—(1) The ability of an application deployed in one WebLogicServer version to communicate with another application that is deployed in adifferent WebLogic Server version. (2) The ability of Oracle product components tocommunicate with third-party software using standard protocols.

• Compatibility—The capability of an application built using one WebLogic Serverrelease to run in another WebLogic Server release, regardless of whether theapplication was rebuilt.

Upgrading From a WebLogic Version Prior to WebLogicServer 10.3.6

To upgrade to WebLogic Server 14.1.1.0.0 from a version prior to 10.3.1, you must firstupgrade to WebLogic Server 10.3.6, and then upgrade to 14.1.1.0.0.

If you are currently using a WebLogic version prior to WebLogic Server 10.3.6,upgrading to version 14.1.1.0.0 is a two-stage process:

• Upgrade your installation to WebLogic Server 10.3.6.

To do so, follow the instructions in Upgrade Guide for WebLogic Server 10.3.6 athttp://docs.oracle.com/middleware/11119/wls/WLUPG/intro.htm.

Be sure to run the WebLogic Server 10.3.6 Domain Upgrade Wizard to upgradeyour domains.

Note:

To download a WebLogic Server 10.3.6 upgrade installer, enter theappropriate patch number on My Oracle Support:

– Patch 13529623—10.3.6 Generic Upgrade Installer (does notinclude a bundled JDK)

– Patch 13529653—10.3.6 Linux 32-bit Upgrade Installer

– Patch 13529639—10.3.6 Windows 32-bit Upgrade Installer

– Patch 13529649—10.3.6 Solaris 32-bit Upgrade Installer

Chapter 1Upgrading From a WebLogic Version Prior to WebLogic Server 10.3.6

1-3

• Upgrade WebLogic Server 10.3.6 to WebLogic Server 14.1.1.0.0 per theinstructions in this guide.

Note:

As of WebLogic Server 12.1.2, Oracle no longer provides upgradeinstallers. You must install WebLogic Server 14.1.1.0.0 to a new directorylocation. You cannot install it over an existing installation.

Overview of the Upgrade ProcessYou can upgrade all WebLogic Server applications and domains simultaneously,upgrade them in a well-defined sequence, or upgrade some applications and domainswhile leaving other applications and domains on older WebLogic Server versions.

The process required to upgrade an application environment depends on the scopeof the application. An application environment includes a WebLogic domain and anyapplications and application data associated with the domain. It may also includeexternal resources, such as firewalls, load balancers, and LDAP servers. Figure 1-1shows an example of a WebLogic application environment.

Figure 1-1 Example WebLogic Application Environment

Table 1-1 lists the components of the WebLogic application environment shown inFigure 1-1 and the upgrade requirements for each.

Chapter 1Overview of the Upgrade Process

1-4

Table 1-1 Upgrade Requirements for Components in Example WebLogic ApplicationEnvironment

Component Description Upgrade Requirements

WebLogic domain Includes the Administration Server (AS) and optionallyone or more Managed Servers (for example, MS1,MS2, MS3, and MS4). The servers in a domainmay span multiple machines. Furthermore, you cangroup Managed Servers into clusters to supportload balancing and failover protection for criticalapplications. For more information about WebLogicdomains, see Understanding Oracle WebLogic domainsin Understanding Domain Configuration for OracleWebLogic Server.

Upgrade the domain directory oneach computer in the domain.

Applications Any Java EE applications, including Web applications,EJBs, and so on. Typically, applications are deployed toone or more Managed Servers in a domain. Dependingon the deployment strategy, applications may residelocally on a computer or be accessible using a shareddirectory. In addition, external client applications mayaccess the application environment from outside afirewall.

Most WebLogic Serverapplications can be run withoutmodifications in the newWebLogic Server 14.1.1.0.0application environment. SeeInteroperability and Compatibilitywith Previous Releases.

External resources Software components, such as databases for storingdomain and application data, load balancers, andfirewalls.

Verify that all external resourcesare compatible with WebLogicServer 14.1.1.0.0. See the OracleFusion Middleware SupportedSystem Configurations page onthe Oracle Technology Network.

Upgrading business applications that are deployed to WebLogic Server may involveupgrading multiple WebLogic Server applications, and in some cases domains, in acoordinated fashion to:

• maintain consistency in the WebLogic Server versions being used

• use the same supported configurations environment across the entire installation

• meet specific interoperability requirements.

Before You BeginBefore you upgrade WebLogic Server, verify that your machine is set up to meet therequirements to upgrade and run WebLogic Server. You must also consider the scopeof the environments that you are upgrading and which applications are upgraded inwhich sequence.

As covering all the permutations of an upgrade is beyond the scope of this document,consider the following items prior to planning your upgrade. These items focus onupgrades that involve a single application running in a single domain.

• Oracle recommends that you upgrade an application in development environmentsand use a standard QA, testing, and staging process to move upgradedapplications to a production environment.

• You typically upgrade an application either by upgrading an existing domain orby creating a new domain, from which you can run the application on the new

Chapter 1Before You Begin

1-5

WebLogic Server version. Sometimes, you prefer to create new domains using theFusion Middleware Configuration Wizard or other configuration tools (such asWLST) to test the applications that you are upgrading.

Note:

If the domain was created using a WebLogic Server version prior toversion 10.3.1, you must first upgrade to WebLogic Server 10.3.6. SeeUpgrading From a WebLogic Version Prior to WebLogic Server 10.3.6.After upgrading to WebLogic Server 10.3.6, run the WebLogic Server10.3.6 Domain Upgrade Wizard to upgrade the domain. You can thenuse the Reconfiguration Wizard to upgrade the domain to WebLogicServer 14.1.1.0.0.

• When planning a WebLogic Server version upgrade, you should review theFusion Middleware Supported Systems Configurations page on Oracle TechnologyNetwork (OTN) to ensure that your upgraded environment is supported by Oracle,in particular:

– current and planned JVM and JDK versions

– operating system versions

– database versions

– Web services versions

– versions of other products that interoperate with or run on WebLogic Server,to ensure that the upgraded environment is supported by Oracle or othervendors' products that you are using with WebLogic Server.

• On an ongoing basis, Oracle documents APIs and features that have beendeprecated (that is, planned for removal in a future release). This is intendedto inform you that you should avoid using these APIs and features to ensureupgradability. Oracle also documents the APIs and features that have actuallybeen removed in the current release so that if you are upgrading from priorversions, you can determine if your applications will be affected by an upgrade.

APIs and feature removals are cumulative. For example, if you are upgradingfrom WebLogic Server 10.0 to WebLogic Server 14.1.1.0.0, your applications maybe affected by APIs or features that were removed in WebLogic Server 10.3, aswell as by APIs or features that were removed in WebLogic Server 14.1.1.0.0.When upgrading, you should review all documentation of deprecated and removedfeatures for all applicable WebLogic Server versions.

• You should consider the impact (if any) that the upgrade process may have on anyautomation (such as WLST scripts) that you are using to configure, deploy, start/stop, or monitor your WebLogic Server applications. You may need to upgradesuch automation along with the applications and domains you are upgrading.

• You should consider the potential impact that may result from the use of third-partylibraries in your applications, as they may conflict with different versions of thosesame libraries that are embedded in WebLogic Server. In particular, new versionsof WebLogic Server may change the version of open source libraries that areembedded in WebLogic Server. Applications that may run successfully on earlierWebLogic Server versions may encounter new class conflicts after upgrade.

Chapter 1Before You Begin

1-6

If you are upgrading an application that contains embedded third-party libraries,you should consider using the Classloader Analysis Tool, and filtering classloaderswhen upgrading WebLogic Server applications to WebLogic Server 14.1.1.0.0.This tool enables you to identify, diagnose and resolve such conflicts, and maysimplify the upgrade process.

• If you are running applications on prior versions of WebLogic Server, and areusing WebLogic Server patches or bug fixes, you should investigate whetheror not those patches or bug fixes have been incorporated into the version ofWebLogic Server to which you are upgrading.

Interoperability and Compatibility with Previous ReleasesMost existing WebLogic Server version 10.3.1 or later applications can be run withoutmodification in the new WebLogic Server 14.1.1.0.0 application environment.

To determine whether any feature changes affect the applications in your environment,review the compatibility information described in WebLogic Server 14.1.1.0.0Compatibility with Previous Releases. If your application uses APIs that have beendeprecated or removed, then you may encounter warnings or exceptions at run time.

Patching an Existing WebLogic Server InstallationYou can patch an existing WebLogic Server installation using either Zero DowntimePatching or manually rolling update of your servers.

Zero Downtime Patching (ZDT Patching) is a highly automated way to roll out updatesto the servers in your domain with no loss of services to your customers. Use thismethod only if your domain contains three or more nodes and all the servers you wantto patch are assigned to clusters. See About Zero Downtime Patching.

Manually performing a rolling update of your servers results in no loss of service toyour customers. Use this method to patch individual servers that are not part of acluster or if the domain contains fewer than three nodes. See About Zero DowntimePatching.

Obtaining a List of Applied Patches explains how you can see the list of patches thathave already been applied to a WebLogic Server instance.

About Zero Downtime PatchingAs of WebLogic Server 12.2.1, you can use Zero Downtime Patching (ZDT Patching)to automate the process of applying patches, bundle patches or patch set updates to aWebLogic Server installation.

With ZDT Patching, you can use the OPatchAuto tool, WLST, or the WebLogic ServerAdministration Console to orchestrate the rollout of updates across some or all of theservers in your domain. In brief, this involves:

• Creating and patching a second Oracle Home. You can do this manually or youcan use OPatchAuto to automate the process.

• Distributing the patched Oracle Home to all of your nodes. Again, you can do thismanually or you can use OPatchAuto to do it for you.

• Using OPatchAuto, WLST, or the WebLogic Server Administration Console toconfigure a patching workflow to update the desired servers in your domain.

Chapter 1Interoperability and Compatibility with Previous Releases

1-7

With ZDT Patching, you can also use a patching workflow to revert patches that youhave previously applied to a WebLogic Server installation using ZDT Patching.

For more details about ZDT Patching, see Administering Zero Downtime PatchingWorkflows.

About Rolling UpdatesA rolling update preserves the state of active client sessions. During the rolling updateprocess, client sessions are failed over from inactive servers to active servers toprovide a seamless experience for your application users.

Rolling update of WebLogic Server refers to the process of installing a patch, bundlepatch, or patch set update to an existing WebLogic Server installation without shuttingdown the entire cluster or domain.

During the rolling update of a cluster, each server in the cluster is individually patchedand restarted while other servers in the cluster continue to operate. You can alsoperform a rolling update on Managed Servers that are not part of a cluster.

Note:

If your installation includes Oracle Enterprise Manager (EM), see PatchingSoftware Deployments in Oracle Enterprise Manager Lifecycle ManagementAdministrator's Guide.

Note the following limitations for rolling updates:

• You cannot use a rolling update to upgrade to a new minor version of WebLogicServer, for example from version 12.1.2 to 12.1.3. You can install only individualpatches, patch bundles, or patch set updates (for example, 12.1.2.0.0 to12.1.2.0.1, 12.1.2.0.1 to 12.1.2.0.2, or 12.1.2.0.0 to 12.1.2.0.5). To upgrade toa new minor version, you must install the new version in a new Oracle Homedirectory. See Installing and Configuring Oracle WebLogic Server and Coherence.

• You must update the machine on which the Administration Server is running first,as that machine must be running the same or a newer version of the software thanthe machines in the domain that are running only Managed Servers.

• For machines on which WebLogic Server is installed, if multiple servers arerunning on the machine, you must shut down all servers on the machine, includingthe Administration Server if it is running on that machine, before you can performthe rolling update.

• You should not make configuration changes during the rolling update process untilall the servers in the domain have been updated. This is especially true for newconfiguration options. Servers silently ignore settings that they do not understand,and the local configuration file may not be updated properly. In addition, using newconfiguration options may prohibit the deinstallation of a patch, patch set, or patchset update in a rolling fashion.

Chapter 1Patching an Existing WebLogic Server Installation

1-8

Note:

For information about performing a rolling update of WebLogic Server12.2.1.3.0 to 12.2.1.4.0, see Performing a Rolling Upgrade to ReduceDowntime in Upgrading to the Oracle Fusion Middleware Infrastructure.

Performing a Rolling UpdateTo perform a rolling update using patches, bundle patches, or patch set updates forOracle WebLogic Server, use the Oracle OPatch tool. The general process is asfollows, starting with the Administration Server. See Patching with OPatch.

1. Back up your applications, database schema, other application data, and domains.

2. Download the WebLogic Server patch, bundle patch, or patch set update to aserver in the cluster.

3. Shut down the server or servers on the machine to be upgraded:

a. Complete any pending processes.

b. Gracefully shut down the server or servers.

4. Apply the patch or patch set update.

5. Restart the server or servers.

6. Repeat the above steps for each server machine you need to patch.

Note:

As a best practice, in order to preserve the state of active clientsessions, you should wait a reasonable amount of time before shuttingdown the servers on the next machine in your upgrade sequence. Theamount of time that you should wait can be as little as 5-10 minutes,depending on how long it takes your applications to invalidate idle clientsessions.

About WebLogic Server Cluster Messaging

In 12.2.1.4.0, WebLogic Server cluster messaging was enhanced. If all of the serversin a cluster are running the same installation version of WebLogic Server, no changesare required.

When you perform a rolling upgrade from 12.2.1.3.0 to 12.2.1.4.0 or a downgradefrom 12.2.1.4.0 to 12.2.1.3.0, the newer 12.2.1.4.0 servers must be explicitly set,to temporarily allow the older protocol. You can do this by setting the systemproperty weblogic.upgradeExpirationDate with an expiration date, which enables the12.2.1.4.0 server to allow communication on the cluster until that expiration date andtime is reached. For example:

-Dweblogic.upgradeExpirationDate=2020-01-05T08:47

Chapter 1Patching an Existing WebLogic Server Installation

1-9

If you want the clusters that are at different versions, to continue to communicate foran extended period of time, you must set the value to a preferred future upgrade date.

Note:

The system property -Dweblogic.upgradeExpirationDate must be usedin the Server Start arguments for each of the Managed Servers, andnot in the JAVA_OPTIONS environment variable in the startWebLogic.sh orstartWebLogic.cmd scripts.

Rolling Back a Patch, Bundle Patch, or Patch Set UpdateUse the Oracle OPatch tool to roll back an applied patch, bundle patch, or patch setupdate.

• To roll back a single patch, see Rolling Back a Patch You Have Applied.

• To roll back multiple patches, see Rolling Back Multiple Patches You HaveApplied.

Obtaining a List of Applied Patches

Oracle WebLogic Server provides the ability to display the list of patches that havebeen applied to a WebLogic Server instance. The patch list can be obtained fromeither of the following sources:

• weblogic.log.DisplayPatchInfo System Property

• ServerRuntimeMBean.PatchList Attribute

When you use one of the preceding sources, the following details are provided foreach applied patch:

• Associated bug number

• Patch number

• Date the patch was applied

• Brief description

The following sections explain the available ways to obtain a server’s list of appliedpatches.

weblogic.log.DisplayPatchInfo System Property

The weblogic.log.DisplayPatchInfo system property contains a log of all patchesthat have been applied to a WebLogic Server instance, and can be accessed by eitherof the following methods:

• Specifying the -Dweblogic.log.DisplayPatchInfo=true JVM option in thecommand line that starts the server instance. As the server starts, the startupmessages in stdout include the list of applied patches, and they are also retainedin the server log file. Note that to minimize logging overhead during startup, thedefault value of this option is false.

Chapter 1Patching an Existing WebLogic Server Installation

1-10

• Running the weblogic.version utility. This utility can obtain the patch listregardless of whether the -Dweblogic.log.DisplayPatchInfo=true startup optionis used, and does not require the WebLogic Server instance to be starting orrunning.

The following example shows running the weblogic.version utility. This exampleincludes specifying the classpath of the weblogic.jar file corresponding to the specificserver instance whose patch list is to be displayed.

bash-4.1$ java -classpath wlserver/server/lib/weblogic.jar weblogic.version

WebLogic Server 12.2.1.1.0 Thu Jun 2 16:21:58 PDT 2016 178483824907328;20845986;Mon Mar 13 14:40:42 PDT 2017;WLS PATCH SET UPDATE 12.2.1.1.17011719795066;19149348;Mon Mar 13 14:33:28 PDT 2017;One-off18905788;18668039;Mon Mar 13 14:32:57 PDT 2017;One-off19632480;19278519;Mon Mar 13 14:32:26 PDT 2017;One-off19002423;18804275;Mon Mar 13 14:31:50 PDT 2017;One-off19030178;19234068;Mon Mar 13 14:31:22 PDT 2017;One-off19154304;19278518;Mon Mar 13 14:30:54 PDT 2017;One-off Use 'weblogic.version -verbose' to get subsystem information Use 'weblogic.utils.Versions' to get version information for all modules

ServerRuntimeMBean.PatchList Attribute

The list of patches that have been applied to a WebLogic Server instance is alsoavailable from the ServerRuntimeMBean.PatchList attribute. The value of this attributeis independent of the weblogic.log.DisplayPatchInfo system property. You canaccess the ServerRuntimeMBean.PatchList attribute using any of the following clients:

• WLST — See Example 1-1

• REST API — See Example 1-2

• WebLogic Server Administration Console — See Example 1-3

• JMX — See Example 1-4

Note:

To access the patch list from the ServerRuntimeMBean, you must be anauthenticated user whose identity can be mapped to the Admin role.

Regardless of the client that you use to obtain patch information, each patch entry hasthe following format:

<BugNumber>;<PatchID>;<DateApplied>;<Description>

Example 1-1 Using WLST

The following example shows using WLST to connect to a server instance and obtainits list of applied patches:

wls:/offline> connect('username','password','t3://localhost:7001')Connecting to t3://localhost:7001 with userid weblogic ...Successfully connected to Admin Server "myserver" that belongs to domain "mydomain".

Chapter 1Patching an Existing WebLogic Server Installation

1-11

Warning: An insecure protocol was used to connect to the server.To ensure on-the-wire security, the SSL port or Admin port should be used instead. wls:/mydomain/serverConfig/> serverRuntime()Location changed to serverRuntime tree. This is a read-only tree with ServerRuntimeMBean as the root.For more help, use help('serverRuntime'). wls:/mydomain/serverRuntime/> print cmo.getPatchList()array(java.lang.String,['24907328;20845986;Mon Mar 13 14:40:42 PDT 2017;WLS PATCH SET UPDATE 12.2.1.1.170117', '19795066;19149348;Mon Mar 13 14:33:28 PDT 2017;One-off', '18905788;18668039;Mon Mar 13 14:32:57 PDT 2017;One-off', '19632480;19278519;Mon Mar 13 14:32:26 PDT 2017;One-off', '19002423;18804275;Mon Mar 13 14:31:50 PDT 2017;One-off', '19030178;19234068;Mon Mar 13 14:31:22 PDT 2017;One-off', '19154304;19278518;Mon Mar 13 14:30:54 PDT 2017;One-off'])wls:/mydomain/serverRuntime/>

Example 1-2 Using the REST API

The following example shows using the REST API to return the patch list:

Request:http://localhost:7001/management/weblogic/latest/serverRuntime?links=none&fields=name,patchList

Response: { "patchList": [ "24907328;20845986;Mon Mar 13 14:40:42 PDT 2017;WLS PATCH SET UPDATE 12.2.1.1.170117", "19795066;19149348;Mon Mar 13 14:33:28 PDT 2017;One-off", "18905788;18668039;Mon Mar 13 14:32:57 PDT 2017;One-off", "19632480;19278519;Mon Mar 13 14:32:26 PDT 2017;One-off", "19002423;18804275;Mon Mar 13 14:31:50 PDT 2017;One-off", "19030178;19234068;Mon Mar 13 14:31:22 PDT 2017;One-off", "19154304;19278518;Mon Mar 13 14:30:54 PDT 2017;One-off" ], "name": "myserver"}

Example 1-3 Using the WebLogic Server Administration Console

To use the WebLogic Server Administration Console:

1. In the left pane of the Console, expand Environment and select Servers.

2. Select the name of the server whose applied patch list you want to view.

3. Select Configuration > General > Monitoring.

The list of applied patches is displayed beneath the field labeled Patch List.

Example 1-4 Using a JMX Client

Using a JMX application, you can access the applied patch list of a WebLogic Serverinstance by invoking the getPatchList method, as in the following example:

/** * @include-api for-public-api * Returns array of informational strings for installed patches. Each info string * is of the form: <bug-id>;<patch-id>;<date-applied>;<patch-description> * For example:

Chapter 1Patching an Existing WebLogic Server Installation

1-12

* 24907328;20845986;Mon Mar 13 14:40:42 PDT 2017;WLS PATCH SET UPDATE 12.2.1.1.170117 * * @return Array of informational strings for installed patches at a server. * @roleAllowed Monitor * @unharvestable */public String[] getPatchList();

Chapter 1Patching an Existing WebLogic Server Installation

1-13

2Roadmap for Upgrading Your ApplicationEnvironment

Use the upgrade roadmap to identify the procedure required to upgrade your OracleWebLogic Server application environment. An upgrade of WebLogic applicationenvironment is complete when you upgrade, configure, and deploy your WebLogicapplication environments.

This document describes the upgrade process for Oracle product installations thatinclude only WebLogic Server. If your installation includes other Oracle FusionMiddleware products, prior to beginning the upgrade, refer to Planning an Upgradeof Oracle Fusion Middleware and the upgrade guides for each Fusion Middlewareproduct in your installation.

Complete the following steps to upgrade your application environment:

• Plan for an Upgrade

• Prepare for the Upgrade

• Upgrade Your Application Environment

• Procedure for Upgrading an Application Environment

• What to Do If the Upgrade Process Fails

Plan for an UpgradeBefore upgrading your WebLogic application environment, plan the upgrade path.Planning the upgrade path includes generating an inventory of the applicationenvironment, verifying the supported system configurations, reviewing the compatibilityinformation of application environment, and creating an upgrade plan.

To ensure that your plan addresses all the aspects of upgrading that are necessary foryour environment, complete the following steps:

• Step 1: Inventory the Application Environment

• Step 2: Verify Supported Configuration Information

• Step 3: Review the Compatibility Information

• Step 4: Create an Upgrade Plan

Step 1: Inventory the Application EnvironmentGenerate an inventory of the application environment by identifying the followingcomponents:

• Administration Server and the computer on which it resides

• Managed Servers and the computer(s) on which they reside

• Location of the applications (including all external client applications)

2-1

• External resources, for example:

– Databases used to store persisted and application data

– Firewalls

– Load balancers

• Tools, scripts, templates, and source code used for automating the tasks requiredto create the application environment

You can view a sample application environment in Overview of the Upgrade Process.

Step 2: Verify Supported Configuration InformationSupported configurations (for example, JDK versions, Operating System versions,Web server versions, and database versions) have changed for WebLogic Server14.1.1.0.0. You may be required to upgrade your environments to the supportedversions of these and other products.

For information about supported configurations, see Oracle Fusion MiddlewareSupported System Configurations on Oracle Technology Network (OTN).

For databases, note that:

• WebLogic Server 14.1.1.0.0 supports PointBase 5.7. However, PointBase is nolonger included in the WebLogic Server installation program. Derby replacesPointBase for running WebLogic Server samples.

To upgrade to WebLogic Server 14.1.1.0.0, you must create a new WebLogicServer installation. Therefore, the PointBase installation directory is not included.To continue using PointBase, see Upgrading a Domain that Uses an EvaluationDatabase.

Note: The pre-5.7 version of PointBase that was distributed with earlier versions ofWebLogic Server can be used only for WebLogic domains.

• As of WebLogic Server 10.3.3, the evaluation database available from theinstallation program that is provided for use by the sample applications and codeexamples, and as a demonstration database, is changed from PointBase to Derby.Derby is an open source relational database management system based onJava, JDBC, and SQL standards. For more information about Derby, see http://db.apache.org/derby/.

If you have a domain based on PointBase from an earlier version of WebLogicServer, and you plan to upgrade that domain to WebLogic Server 14.1.1.0.0,you can continue to use PointBase. But you must obtain a license from http://www.pointbase.com to use it. See Upgrading a Domain that Uses an EvaluationDatabase.

• As of WebLogic Server 10.3, the Oracle Thin Drivers are included as part of theWebLogic Server installation.

• If you are using an Oracle OCI database driver and want to change to use a Thindatabase driver, you must remove the server property (as illustrated below) fromthe generated JDBC module. For example:

<property> <name>server</name> <value>servername</value> </property>

Chapter 2Plan for an Upgrade

2-2

• The Oracle Thin Drivers are installed with WebLogic Server and are ready foruse. For more information about using these drivers, see JDBC Drivers Installedwith WebLogic Server in Administering JDBC Data Sources for Oracle WebLogicServer.

Step 3: Review the Compatibility InformationMost existing WebLogic Server applications can be run without modification inthe new WebLogic Server 14.1.1.0.0 application environment. However, you shouldreview WebLogic Server 14.1.1.0.0 Compatibility with Previous Releasesto determinewhether any feature changes affect the applications in your environment.

Step 4: Create an Upgrade PlanUsing the information gathered in the preceding steps, create a plan for upgradingyour application environment.

Identify the scope and timing of the upgrade process, based on your business needs.Note the following points:

• Oracle does not recommend upgrading an application environment that iscurrently deployed in production. Instead, you should upgrade your applicationenvironment while it is under development or test and execute standardprocedures for quality assurance and performance tuning before promoting theupgraded environment to production.

• If your application is complex, for example, if it includes multiple clustered domainsand a large number of deployed applications, you may choose to upgrade thecomponents of the application environment in stages.

• You may consider limiting the number of WebLogic Server versions used in anysingle application environment to minimize the diversity and cost of systems beingadministered.

• If you plan to use the RDBMS security store in a WebLogic domain, Oraclerecommends that you create a new domain in which the RDBMS security storeis configured. If you have an existing domain in which you want to use the RDBMSsecurity store, you should create the new domain, and then migrate your securityrealm to it. Oracle does not recommend "retrofitting" the RDBMS security storeto an existing domain. See Managing the RDBMS Security Store in AdministeringSecurity for Oracle WebLogic Server.

Prepare for the UpgradeBefore you start the upgrade process, you should verify whether there are anyupgrade compatibility issues that apply to your applications. You then shut down allrunning server instances and back up the application components in your domain.

Complete the following tasks before you upgrade the application environment:

• Step 1: Check Your Applications (Undeploy If Necessary)

• Step 2: Shut Down Servers in the Application Environment

• Step 3: Back Up the Application Environment

• Step 4: Install Required Oracle Products

Chapter 2Prepare for the Upgrade

2-3

• Step 5: Set Up the Environment

Step 1: Check Your Applications (Undeploy If Necessary)It is not necessary for WebLogic Server applications to be undeployed beforeupgrading the domain. In most cases, WebLogic Server applications can berun without modifications in the new WebLogic Server 14.1.1.0.0 applicationenvironment. To determine whether any features changes affect the applications inyour environment, review the compatibility information in WebLogic Server 14.1.1.0.0Compatibility with Previous Releases. Note that if you use deprecated or removedAPIs in the application, you might encounter warnings or exceptions at run time.

Step 2: Shut Down Servers in the Application EnvironmentBefore you upgrade, you must shut down all servers in the application environment.

Step 3: Back Up the Application EnvironmentOracle recommends that before upgrading your application environment, you manuallyback up the components defined in Table 2-1. You should back up the relevantinformation on all machines in the domain.

Table 2-1 Recommendations for Backing Up the Application Environment

Component Recommendations

Domain directory Back up the Administration Server and any remote Managed Serverdomain directories that are defined in the application environment.

Note: The Domain Upgrade Wizard, which automatically backed up thedomain being upgraded, is no longer provided with WebLogic Server.You must manually back up your domain directory prior to upgrading thedomain.

Applications andapplication-persisteddata

Back up any applications and data that reside outside of the domaindirectory.

Log files If it is important for you to maintain a record of all messages that arelogged, back up the log files. As log files can be large, you may want todelete them to conserve disk space if it is not important to retain them.

Step 4: Install Required Oracle ProductsBefore upgrading your application environment, you must install the Oracle WebLogicServer 14.1.1.0.0 products that you require on each computer in the domain. For moreinformation about installing Oracle WebLogic products, see Installing and ConfiguringOracle WebLogic Server and Coherence.

Step 5: Set Up the EnvironmentTo set up the environment for an upgrade:

1. Open an MS-DOS command prompt window (on Windows) or a command shell(on UNIX).

Chapter 2Prepare for the Upgrade

2-4

2. Add the WebLogic Server classes to the CLASSPATH environment variable andWL_HOME\server\bin to the PATH environment variable, where WL_HOME refers tothe top-level installation directory for WebLogic Server.

You can perform this step by running the WL_HOME\server\bin\setWLSEnv script.

Note:

On UNIX operating systems, the setWLSEnv.sh command does not setthe environment variables in all command shells. Oracle recommendsthat you execute this command using the Korn shell or bash shell.

Upgrade Your Application EnvironmentThe specific upgrade steps you perform depend upon whether you are upgradingfrom WebLogic Server 10.3.0 or earlier, whether other Fusion Middleware products areinstalled, and whether Managed Servers are installed on remote machines.

Figure 2-1 shows the steps required to upgrade your application environment.

Chapter 2Upgrade Your Application Environment

2-5

Figure 2-1 Roadmap for Upgrading Your Application Environment

Chapter 2Upgrade Your Application Environment

2-6

Procedure for Upgrading an Application EnvironmentTo upgrade your application environment to the latest version of WebLogic Server,you may first need to upgrade to 10.3.6. You then back up the domain, upgrade theAdministration Server host machine, configure the Node Manager, and upgrade eachManaged Server instance.

The Table 2-2table summarizes the steps for updating an application environment.Each step that is performed must be done on every computer in the domain and in thegiven sequence shown in this table.

Table 2-2 Procedure for Upgrading an Application Environment

Task Description

Upgrade to WebLogic Server10.3.6

If the domain was created prior to WebLogic Server 10.3.0, you must firstupgrade to WebLogic Server 10.3.6. You can do this using the WebLogicServer 10.3.6 upgrade installer.

See Installation Guide for Oracle WebLogic Server 10.3.6.

Run the Domain Upgrade Wizard If the domain was created prior to WebLogic Server 10.3.0, run the WebLogicServer 10.3.6 Domain Upgrade Wizard to upgrade the domain. See UpgradingDomains Created Prior to WebLogic Server 10.3.0.

Back up the domain Before upgrading the domain on the Administration Server, ensure to backupthe domain. See Backing Up the Domain.

Upgrade WebLogic domain(Administration Server)

Run the Reconfiguration Wizard to upgrade the WebLogic domain on thecomputer that hosts the Administration Server. See Reconfiguring a WebLogicDomain.

Notes: Oracle recommends that you completely upgrade the domain on theAdministration Server before upgrading the domain on the Managed Servers.

Depending on the Node Manager configuration of the original domain andthe desired Node Manager configuration of the upgraded domain, you maybe able to upgrade Node Manager by using the Reconfiguration Wizard. SeeDetermining Node Manager Upgrade Procedure.

Complete Node Managerconfiguration

If necessary, configure Node Manager as a per host Node Manager. Thisis needed only if your existing domain is using a per host Node Managerconfiguration and you want to continue using a per host Node Manager in theupgraded domain. See Completing the Node Manager Configuration.

Back up the domain on eachManaged Server.

Prior to upgrading the domain on a Managed Server, make a backup copy ofthe domain. See Backing Up the Domain.

Upgrade WebLogic domain(remote Managed Servers)

Use the pack and unpack commands or the WLST writeTemplate()command in online mode to upgrade the WebLogic domain on every computerthat hosts any Managed Servers.

See Also:• Updating a Managed Server Domain on a Remote Machine• Creating Templates and Domains Using the Pack and Unpack Commands

Note:• The unpack command works only with the same version used to pack the

WebLogic domain.• Managed Servers that reside on the same computer as the Administration

Server do not require additional upgrade steps.

Chapter 2Procedure for Upgrading an Application Environment

2-7

What to Do If the Upgrade Process FailsIf any step in the upgrade process fails, the Reconfiguration Wizard displays amessage indicating the reason for the failure, and then terminates the upgradeprocess.

To proceed with the upgrade process, perform the following steps:

1. Restore the application environment to its original state using the backup files youcreated in Step 3: Back Up the Application Environment.

2. Correct the failure reported by the Reconfiguration Wizard.

3. Run the Reconfiguration Wizard again to upgrade the domain.

Chapter 2What to Do If the Upgrade Process Fails

2-8

3Reconfiguring WebLogic Domains

You can use the Reconfiguration Wizard to upgrade any WebLogic domain that wascreated with Oracle WebLogic Server 10.3.1 or later, or from Oracle WebLogic Server12.1.1 or later.

When you use the Reconfiguration Wizard to reconfigure a WebLogic Server domain,the following items are automatically updated, depending on the applications in thedomain:

• WLS core infrastructure

• Domain version

Note:

The Reconfiguration Wizard does not update any of your applications thatare included in the domain. For information about how to upgrade yourapplications, see WebLogic Server 14.1.1.0.0 Compatibility with PreviousReleases.

Learn how to use the Reconfiguration Wizard to reconfigure WebLogic Serverdomains.

• Before You Begin

• Reconfiguring a WebLogic Domain

• Updating a Managed Server Domain on a Remote Machine

• Important Notes About the Domain Upgrade Process

• Upgrading a Domain that Uses an Evaluation Database

Before You BeginBefore you run the Reconfiguration Wizard, make sure the domain is upgraded toversion WebLogic Server 10.3.6, if necessary. You then perform additional tasks, suchas configuring the CONFIG_JVM_ARGS environment variable, backing up the domain, andchoosing the Node Manager configuration that you want to use with the upgradeddomain.

Upgrading Domains Created Prior to WebLogic Server 10.3.0Domains created with WebLogic Server versions 10.3.0 and later can be upgradeddirectly to version 14.1.1.0.0. However, if your domain was created prior to WebLogicServer 10.3.0, you must first upgrade it to WebLogic Server 10.3.6.

3-1

After upgrading to WebLogic Server 10.3.6, run the Domain Upgrade Wizard toupgrade the domain.

To upgrade to WebLogic Server 10.3.6 and run the Domain Upgrade Wizard, seeUpgrade Guide for Oracle WebLogic Server 10.3.6 at the following URL:

http://docs.oracle.com/cd/E23943_01/web.1111/e13754/toc.htm

Setting CONFIG_JVM_ARGS on UNIX and Linux SystemsPrior to running the Reconfiguration Wizard to reconfigure a domain on a UNIX orLinux operating system, if you have not already done so, set the CONFIG_JVM_ARGSenvironment variable to the following value to use the operating system's randomnumber generator:

-Djava.security.egd=file:/dev/./urandom

This decreases the amount of time it takes for the Reconfiguration Wizard toreconfigure a domain.

Backing Up the DomainPrior to running the Reconfiguration Wizard, make a backup copy of the domaindirectory. For example, copy C:\domains\mydomain to C:\domains\mydomain_backup.

Prior to updating the domain on each remote Managed Server, make a backup copy ofthe domain directory on each remote machine.

If domain reconfiguration fails for any reason, you must copy all files and directoriesfrom the backup directory into the original domain directory to ensure that the domainis returned entirely to its original state prior to reconfiguration.

Determining Node Manager Upgrade ProcedurePrior to WebLogic Server 12.1.2, a default Node Manager configuration was providedby WebLogic Server using a default startup script and a default Node Managerhome location. By default, any new domains that were created on that machine wereassociated with the Node Manager in the default Node Manager location. This iscommonly referred to as a per host Node Manager.

Starting WebLogic Server 12.1.2, a Node Manager default configuration is a perdomain Node Manager configuration. That is, the Node Manager configuration isspecific to a given domain. This configuration allows multiple domains on a givenmachine to have different Node Manager configurations. See Default Node ManagerConfiguration in Administering Node Manager for Oracle WebLogic Server.

Table 3-1 shows the supported Node Manager upgrade paths when upgradingWebLogic Server from version 12.1.1 or earlier to the current version, or whenupgrading from version 12.1.2 or later to the current version. Per host in this contextmeans any Node Manager configuration that is outside of your per domain NodeManager configurations.

Chapter 3Before You Begin

3-2

Table 3-1 Supported Node Manager Upgrade Paths

Node Manager UpgradePaths

From WebLogic Server 12.1.1or earlier

From WebLogic Server12.1.2 or later

Per domain to per domain Not available Supported

Per domain to per host Not available Not supported

Per host to per domain Supported Supported

Per host to per host Manual configuration Manual configuration

Table 3-2 shows the Node Manager upgrade details for each supported upgrade path.

Table 3-2 Node Manager Upgrade Details

Per Domain toPer Domain

Per Host to Per Domain Per Host to Per Host

This is anautomaticupgrade for allWebLogic Server12.1.2 or laterreleases that arealreadyconfigured for perdomain NodeManager. Theenvironment isupdated tostandard settingsand can becustomized later.

The upgrade isautomaticwhether you areusing theReconfigurationWizard or WLSTto upgrade thedomain.

In this case, the Reconfiguration Wizardprovides a Node Manager screen duringdomain reconfiguration. Use this screento select the Node Manager configurationto use for the reconfigured domain. Theresulting configuration depends on thecombination of options that you selectfor Node Manager Type and NodeManager Configuration.

You can also use WLST to upgrade thedomain and Node Manager configurationas desired. See Reconfiguring aWebLogic Domain Using WebLogicScripting Tool.

If multiple per domain Node Managersrun on the same machine, seeConfiguring Multiple Per Domain NodeManagers on the Same Machine.

Click the Help button on thescreen on the Fusion MiddlewareReconfiguration Wizard window to seethe Reconfiguration Wizard Context-Sensitve Help.

Node Manager configurationmust be completed manuallyas described in Completing theNode Manager Configuration.

If only some 11g domainsare upgraded to 14c, youwould need to configure asecond Node Manager forthe 14c domains. Beforestarting the reconfigurationprocess, see Running Two PerHost Node Managers on theSame Machine. After domainreconfiguration, complete theNode Manager configuration asdescribed in Completing theNode Manager Configuration(Two Per Host Node Managers).

Configuring Multiple Per Domain Node Managers on the Same MachineIf you have multiple domains on the same machine using a Per Domain NodeManager configuration, when running the Reconfiguration Wizard, do the following:

• If you are upgrading an 11g domain, the Node Manager screen appears. Selecteither Per Domain Default Location or Per Domain Custom Location.

• On the Advanced Configuration screen, select Managed Servers, Clusters, andCoherence to reconfigure the existing machines for the 14c Node Manager.

• No changes are needed on the Managed Servers and Clusters screens. When theMachines screen appears, ensure that you use a unique Node Manager port foreach domain. For example, if you have three per domain Node Managers running

Chapter 3Before You Begin

3-3

on the machine, use port 5556 for Domain 1, port 5557 for Domain 2, and port5558 for Domain 3.

Click the Help button on the screen on the Fusion Middleware ReconfigurationWizard window to see the Reconfiguration Wizard Context-Sensitve Help .

Running Two Per Host Node Managers on the Same MachineIf all the following items apply to your upgrade scenario, extra steps are needed duringthe reconfiguration process to create a second Node Manager for the 14c domains:

• You want to upgrade only some of your 11g or 12c domains to 14c.

• You want to continue using a per host Node Manager for the 14c domains.

• Both 11g/12c and 14c per host Node Managers are running on the same machine.

When running the Reconfiguration Wizard:

• On the Node Manager screen, select Manual Node Manager Setup. This optionkeeps the Node Manager configuration as a per host Node Manager for the 14cdomain being upgraded.

• On the Advanced Configuration screen, select Managed Servers, Clusters, andCoherence to reconfigure the existing machines for the 14c Node Manager. Inaddition, select Deployments and Services to check machine assignments foryour deployments and services.

• No changes are needed on the Managed Servers and Clusters screens. When theMachines screen appears, change the name of each machine to something otherthan the name that is being used for the 11g or 12c domains. In addition, enter aNode Manager port number that is different than the Node Manager port numberthat is being used for the 11g or 12c Node Manager. Use the same port number foreach 14c machine in this domain.

• Verify that your deployments and services are assigned to the new machinenames.

Reconfiguring a WebLogic DomainOracle provides a choice of two tools for reconfiguring a WebLogic domain: thegraphical Fusion Middleware Reconfiguration Wizard or the WebLogic Scripting Tool(WLST).

Caution:

Once the domain reconfiguration process starts, it is irreversible. Beforeusing the Reconfiguration Wizard or WLST to upgrade the domain, ensurethat you have backed up the domain as described in Backing Up theDomain. If an error or other interruption occurs during the reconfigurationprocess, you must restore the domain by copying the files and directoriesfrom the backup location to the original domain directory. This workaround isthe only way to ensure that the domain has been returned to its original statebefore reconfiguration.

When you reconfigure a domain:

Chapter 3Reconfiguring a WebLogic Domain

3-4

• The domain version number in the config.xml file for the domain is updated tothe Administration Server's installed WebLogic Server version major and minorversion number (for example, 14.1.1.0).

• Reconfiguration templates for all installed Oracle products are automaticallyselected and applied to the domain. These templates define any reconfigurationtasks that are required to make the WebLogic domain compatible with the currentWebLogic Server version.

• Start scripts are updated.

• After reconfiguring the domain on the Administration Server, you must port thereconfigured domain to all remote Managed Servers in the domain. See Updatinga Managed Server Domain on a Remote Machine.

• After reconfiguring a domain to a per host Node Manager by using either WLSTor the Reconfiguration Wizard, you must take additional steps to complete theNode Manager configuration. See Completing the Node Manager Configurationand Completing the Node Manager Configuration (Two Per Host Node Managers).

Reconfiguring a WebLogic Domain in Graphical ModeTo reconfigure a domain using the Reconfiguration Wizard, you first launch it from aDOS command prompt or UNIX shell, and then provide the required upgrade details ina sequence of screens that are displayed.

Note:

If you cannot run the Reconfiguration Wizard in GUI mode, Oraclerecommends that you use a WLST script to reconfigure your domain. SeeReconfiguring a WebLogic Domain Using WebLogic Scripting Tool.

To start the Reconfiguration Wizard in graphical mode from a Windows commandprompt or on UNIX systems:

1. Log in to the system on which the domain resides.

2. Open an MS-DOS command prompt window (on Windows) or a command shell(on UNIX).

3. Go to the following directory, where ORACLE_HOME is your Oracle home directory:

On Windows: ORACLE_HOME\oracle_common\common\bin

On UNIX: ORACLE_HOME/oracle_common/common/bin

4. Run the following commands:

On Windows: reconfig.cmd

On UNIX: sh reconfig.sh

Chapter 3Reconfiguring a WebLogic Domain

3-5

Note:

When you run the reconfig.cmd or reconfig.sh command, the followingerror message appears if the default cache directory is not valid:

*sys-package-mgr*: can't create package cache dir

You can change the cache directory by including the -Dpython.cachedir=valid_directory option in the command.

To create a log file of the Reconfiguration Wizard session, include the-log=reconfig.log -log_priority=debug parameter in the command.You can specify any file name for the log file, such as config_today.log.The log file is stored in the logs directory of the Oracle Home directory.Other valid values for log_priority are OFF, SEVERE, WARNING, INFO,CONFIG, FINE, FINER, FINEST, and ALL.

The Select Domain screen appears.

The Reconfiguration Wizard displays a sequence of screens in the order listed inTable 3-3.

Note:

Depending on the applications in your domain and other factors, extraconfiguration screens appear in addition to the screens shown in thefollowing table. For information on these screens, click the Help button onthe screen.

If the Advanced Configuration screen appears during the reconfigurationprocess, do not select any options to skip all advanced configuration. Ifnecessary, you can use WLST, the Configuration Wizard, or the WebLogicServer Administration Console later to perform advanced configuration suchas adding more servers and clusters or changing deployment targeting.

Table 3-3 Reconfiguring an Existing WebLogic Domain

Screen When Does This ScreenAppear?

Perform the Following Action

Select Domain Always Enter the full path to the domain directory orclick Browse to navigate to and select thedomain directory.

Click Next to continue.

ReconfigurationSetup Progress

Always Shows the progress of the application ofreconfiguration templates.

When the process completes, click Next tocontinue.

Chapter 3Reconfiguring a WebLogic Domain

3-6

Table 3-3 (Cont.) Reconfiguring an Existing WebLogic Domain

Screen When Does This ScreenAppear?

Perform the Following Action

ReconfigurationSummary

Always Displays the information about thereconfiguration process for all thereconfigured templates.

Click Next to continue.

Domain Mode andJDK

Always Domain mode cannot be changed.

Select the JDK to use in the domain or clickBrowse to navigate to the JDK you want touse.

Click Next to continue.

Additional domainconfigurationscreens may appearat this point

Additional screensdepend on the domainconfiguration

Click the Help button on the screen or referto Reconfiguration Wizard Screens, whichdescribes all the screens in the order in whichthey are displayed.

AdvancedConfiguration

Always Select the check box for each category (ifany) for which you want to perform advancedconfiguration tasks.

The available check boxes depend on thedomain configuration.

Click Next to continue.

ConfigurationSummary

Always Review the configuration.

Click the Back button to change theconfiguration or click the Reconfig button tocomplete the domain reconfiguration process.

ReconfigurationSuccess

Always Shows the final status of the reconfigurationprocess.

Click Finish to exit the Configuration Wizard.

Reconfiguring a WebLogic Domain Using WebLogic Scripting ToolTo reconfigure a domain using WLST, you use the readDomainForUpgrade command.You can also use this command to migrate an existing per host Node Managerconfiguration to a per domain configuration.

Note:

If the original domain is using a per domain Node Manager configuration,Node Manager is upgraded automatically and no additional steps areneeded.

If the original domain is using a per host Node Manager, and you wantto continue using that configuration, you must manually reconfigure NodeManager as described in Completing the Node Manager Configuration.

Example 3-1 shows how to reconfigure a domain called my_domain using WLST offline.

Chapter 3Reconfiguring a WebLogic Domain

3-7

Example 3-2 shows how to migrate an existing per host Node Manager configurationto a per domain configuration located in DOMAIN_HOME/nodemanager.

Example 3-3 shows how to migrate an existing per host configuration located in /Oracle/Middleware/oracle_common/common/nodemanager to a per domainconfiguration located in /Oracle/Middleware/custom/nodemanager.

For information about available Node Manager options for the setOption command,see setOption in WLST Command Reference for WebLogic Server. For informationabout available Node Manager WLST commands, see Node Manager Commands inWLST Command Reference for WebLogic Server.

Example 3-1 Reconfiguring a WebLogic Domain

# Open the domain for upgrade.wls:/offline> readDomainForUpgrade('c:/domains/my_domain')

# Save the updated domain.wls:/offline/my_domain> updateDomain()

# Close the domain.wls:/offline/my_domain> closeDomain()

If your existing domain is using a per host Node Manager and you want to move to aper domain Node Manager configuration, you have several options:

• Create a per domain configuration in the default location (DOMAIN_HOME/nodemanager) by migrating an existing per host configuration.

• Create a per domain configuration in the default location (DOMAIN_HOME/nodemanager) with a new configuration based on Oracle-recommended defaults.

• Create a per domain configuration in a custom location by migrating an existingper host configuration.

• Create a per domain configuration in a custom location with a new configurationbased on Oracle-recommended defaults.

Example 3-2 Creating a New Node Manager Configuration in the DefaultLocation

#Read domain for reconfigurationreadDomainForUpgrade('domains/mydomain') #Set Node Manager username and password.cd('/')cd('SecurityConfiguration/mydomain')cmo.setNodeManagerUsername('username')cmo.setNodeManagerPasswordEncrypted('password') #Browse Node Manager propertiescd('/')cd('NMProperties') # Create per domain Node Manager with new default configuration. Existing# Node Manager properties will not be migrated in this case.setOption('NodeManagerType','PerDomainNodeManager')setOption('NodeManagerUpgradeType','New') # Update the domain to commit the changes.updateDomain()

Chapter 3Reconfiguring a WebLogic Domain

3-8

Example 3-3 Migrating an Existing Configuration to a Custom Location

#Read domain for reconfigurationreadDomainForUpgrade('/domains/mydomain') #Set Node Manager username and password.cd('/')cd('SecurityConfiguration/mydomain')cmo.setNodeManagerUsername('username')cmo.setNodeManagerPasswordEncrypted('password') #Browse node manager propertiescd('/')cd('NMProperties') # Create custom location Node Manager, migrating an existing Node Manager# configuration with default values for Oracle-recommended default properties.setOption('NodeManagerType','CustomLocationNodeManager')setOption('NodeManagerHome','/Oracle/Middleware/custom/nodemanager/')setOption('NodeManagerUpgradeType','Migrate')setOption('OldNodeManagerHome','/Oracle/Middleware/Oracle_Home/oracle_common/common/nodemanager')setOption('NodeManagerUpgradeOverwriteDefault','true') # Update the domain to commit the changes.updateDomain()

Completing the Node Manager ConfigurationIf the domain you reconfigured was using a per host Node Manager configurationand you want to continue using a per host Node Manager for the domain, you mustcomplete a set of configuration tasks for Node Manager.

1. In the new WebLogic Server installation, create the nodemanager directory inORACLE_HOME/oracle_common/common.

2. Copy the nodemanager.properties and nodemanager.domains files from theWL_HOME/common/nodemanager directory of your previous WebLogic Serverinstallation to the directory you created in Step 1.

3. If your previous installation includes an nm_data.properties,SerializedSystemIni.data, or security/SerializedSystemIni.dat file, copy it to thedirectory you created in Step 1. If copying SerializedSystemIni.dat, you mustcreate a security directory under the nodemanager directory and store the filethere.

4. Make the following edits to the nodemanager.properties file, where ORACLE_HOMEis the Oracle home directory for your WebLogic Server installation:

• Update DomainsFile to point to ORACLE_HOME/oracle_common/common/nodemanager/nodemanager.domains file.

• Update JavaHome to point to the jre directory for the JDK that you are usingfor WebLogic Server. If the file also contains a javaHome property setting(lower-case j), remove it as it is not needed.

• Update NodeManagerHome to point to ORACLE_HOME/oracle_common/common/nodemanager.

• Update LogFile to point to ORACLE_HOME/oracle_common/common/nodemanager/nodemanager.log.

Chapter 3Reconfiguring a WebLogic Domain

3-9

5. If you are using your own security certificates, verify that the location of thosecertificates is correct in nodemanager.properties. You may have to update the pathif you moved the certificates to another location.

If you were using the WebLogic Server demo certificate in your previousinstallation, you must run CertGen to create a demo keystore for this installation:

a. Run setWLSEnv:

cd WL_HOME/server/bin

. ./setWLSEnv.sh (UNIX)

setWLSEnv.cmd (Windows)

Note:

On UNIX operating systems, the setWLSEnv.sh command doesnot set the environment variables in all command shells. Oraclerecommends that you execute this command using the Korn shell orbash shell.

b. Change to the ORACLE_HOME/oracle_common/common/nodemanager/directory and create a security directory if it does not exist.

c. Change to the security directory and enter the following command:

java utils.CertGen -certfile democert -keyfile demokey -keyfilepassDemoIdentityPassPhrase

d. Tto generate the DemoIdentity.jks file, enter the following command:

java utils.ImportPrivateKey -certfile democert.pem -keyfiledemokey.pem -keyfilepass DemoIdentityPassPhrase -keystoreDemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -aliasdemoidentity

6. From the ORACLE_HOME/wlserver/server/bin directory, runstartNodeManager.cmd (Windows) or startNodeManager.sh (UNIX).

7. Verify that you can start servers using Node Manager. See Using Node Managerto Control Servers in Administering Node Manager for Oracle WebLogic Server. Toensure that your permgen settings are adequate for starting the servers, you canuse any one of the following methods:

• Start the Managed Servers using the startManagedWebLogic script.

• Set the StartScriptEnabled value in nodemanager.properties to true,which causes the StartManagedWebLogic script to be invoked when startingManaged Servers.

• Set permgen space as described in Setting permgen space.

• Use a setUserOverrides script to specify permgen settings for server startup.See Customizing Domain Wide Server Parameters in Administering ServerStartup and Shutdown for Oracle WebLogic Server.

Chapter 3Reconfiguring a WebLogic Domain

3-10

Completing the Node Manager Configuration (Two Per Host NodeManagers)

If the domain you reconfigured was using a per host Node Manager configuration, youcan continue using a per host Node Manager for the 14c domain on a machine thatalready has a per host Node Manager for 11g or 12c domains.

Complete the following steps on each machine in the domain:

Note:

Prior to performing the steps in this section, ensure that you haveunpacked the domain to each remote machine in the domain. Include the -nodemanager_type=ManualNodeManagerSetup and -overwrite_domain=trueparameters in the command. For example:

./unpack.sh -domain=domain_home -template=template_jar -nodemanager_type=ManualNodeManagerSetup -overwrite_domain=true

1. In the new WebLogic Server installation, create the nodemanager directory inORACLE_HOME/oracle_common/common.

2. Copy the nodemanager.domains and nodemanager.properties files from theWL_HOME/common/nodemanager directory of your previous WebLogic Serverinstallation to the directory you created in Step 1. If any 11g or 12c domains arelisted in the nodemanager.domains file, delete or comment out those lines.

3. Edit the nodemanager.properties file as appropriate on each machine. Inparticular:

• Verify that the SecureListener is set to true if using an SSL Node Manager,or is set to false if using a Plain Node Manager.

• Change DomainsFile to point to ORACLE_HOME/oracle_common/common/nodemanager/nodemanager.domains.

• Change PropertiesVersion to 14.1.1.0.0.

• Change NodeManagerHome to ORACLE_HOME/oracle_common/common/nodemanager.

• Change JavaHome to point to the jre directory for the Java installation that youare using for WebLogic Server 14.1.1.0.0.

• Remove the javaHome line as it is not needed in 14c.

• Change ListenPort to the value you specified on the Machines screen of theConfiguration Wizard.

• Change LogFile to the desired location and file name. Therecommended value is ORACLE_HOME/oracle_common/common/nodemanager/nodemanager.log.

4. If you are using your own security certificates, verify that the location of thosecertificates is correct in nodemanager.properties. If you moved the certificates toanother location, you have to update the path.

Chapter 3Reconfiguring a WebLogic Domain

3-11

If you used the WebLogic Server demo certificate in your previous installation, youmust run CertGen to create a demo keystore for this installation:

a. Run setWLSEnv:

cd WL_HOME/server/bin

. ./setWLSEnv.sh (UNIX)

setWLSEnv.cmd (Windows)

Note:

On UNIX operating systems, the setWLSEnv.sh command doesnot set the environment variables in all command shells. Oraclerecommends that you execute this command using the Korn shell orbash shell.

b. Change to the ORACLE_HOME/oracle_common/common/nodemanager/ directoryand create a security directory if it does not exist.

c. Change to the security directory and enter the following command:

java utils.CertGen -certfile democert -keyfile demokey -keyfilepassDemoIdentityPassPhrase

d. To generate the DemoIdentity.jks file, enter the following command:

java utils.ImportPrivateKey -certfile democert.pem -keyfiledemokey.pem -keyfilepass DemoIdentityPassPhrase -keystoreDemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -aliasdemoidentity

5. From the ORACLE_HOME/wlserver/server/bin directory, start Node Manager.

6. If the Administration Server is running, restart the Administration Server.

7. Verify that you can start servers using Node Manager. See Using Node Managerto Control Servers in Administering Node Manager for Oracle WebLogic Server. Toensure that your permgen settings are adequate for starting the servers, you canuse any one of the following methods:

• Start the Managed Servers using the startManagedWebLogic script.

• Set the StartScriptEnabled value in nodemanager.properties to true,which causes the StartManagedWebLogic script to be invoked when startingManaged Servers.

• Set permgen space as described in Setting permgen space.

• Use a setUserOverrides script to specify permgen settings for server startup.See Customizing Domain Wide Server Parameters in Administering ServerStartup and Shutdown for Oracle WebLogic Server.

Updating a Managed Server Domain on a Remote MachineIf your WebLogic domain contains multiple Managed Servers, and each ManagedServer domain directory is located on a machine that is remote to the Administration

Chapter 3Updating a Managed Server Domain on a Remote Machine

3-12

Server host machine, you can use one of two methods to update the domain on theremote machine.

• Use the pack command to generate the domain template JAR. Ensure that youinclude the -managed=true argument in the pack command. Move the JAR to theremote machine and then use the unpack command on the remote machine tocreate the Managed Server domain. See Creating Templates and Domains Usingthe Pack and Unpack Commands.

• Use the WLST writeTemplate command in online mode. When you execute thewriteTemplate command while connected to the Administration Server from aremote machine, it dynamically packs the domain on the Administration Serverinto a template JAR file and transfers the template JAR to the specified directory.

The following sample WLST script demonstrates how to use writeTemplate tocreate or update a Managed Server domain on a remote machine. Run the scripton each remote machine in the domain. This script does the following tasks:

– logs in to the Administration Server

– packs the Administration Server domain into a JAR file and writes it to thespecified template directory on the remote machine

– disconnects from the Administration Server

– reads the template JAR

– creates the domain on the remote machine

import os wlsHome = os.getenv('WL_HOME')mwHome = os.path.join(wlsHome, '..') #Substitute the administrator user name and password values below as neededconnect('adminuser','adminpassword','admin_server_url') #Create the path on the local machine where the template will be stored, #The specified template JAR should not already exist. The timeout value #specifies the number of milliseconds to elapse before the connection between#the Administration Server and remote machine times out (default is 120000).templatePath = '/user_templates/myTemplate.jar'timeout = '180000' #get the packed template from the Administration ServerwriteTemplate(templatePath, timeout) #disconnect from online WLST connection to the Administration Serverdisconnect() #read the template that was downloaded from the Administration ServerreadTemplate(templatePath) #specify the domain directory where the domain needs to be createddomainPath = 'domains/myDomain') #create the domainwriteDomain(domainPath)

Chapter 3Updating a Managed Server Domain on a Remote Machine

3-13

Important Notes About the Domain Upgrade ProcessBear in mind several key notes about the domain upgrade process, such as whether itis necessary to undeploy WebLogic Server applications, the minimum set of files thatmust exist in the domain directory, and more.

• It is not always necessary to undeploy WebLogic Server applications. Usually,WebLogic Server applications can run without modifications in the new WebLogicServer 14.1.1.0.0 application environment. Review the compatibility information inWebLogic Server 14.1.1.0.0 Compatibility with Previous Releases to determinewhether any features changes affect the applications in your environment. If APIsthat have been deprecated or removed are used in the application, then you mightencounter warnings or exceptions at run time.

• At a minimum, the domain directory must contain the following files:

– config.xml

– Security-related files, including SerializedSystemIni.dat,DefaultAuthenticatorInit.ldift, DefaultAuthorizerInit.ldift, andDefaultRoleMapperInit.ldift

If the security-related files are not available, the server fails to start and anauthentication error message is logged.

– Any transaction log (.tlog) files that reside in the domain. See TransactionLog Files in Developing JTA Applications for Oracle WebLogic Server.

• All contents of the domain directory on the target computer are updated during thisprocess.

• You must upgrade the domain on every computer in the application environment.

• The reconfiguration wizard does not upgrade your own applications that may existin the domain during a WebLogic domain upgrade.

• Domains that contain resources for WebLogic Liquid Data, or AquaLogic DataServices Platform cannot be upgraded to WebLogic Server 14.1.1.0.0.

• When you upgrade a domain on a remote Managed Server, a message similar tothe following may appear to indicate that the referenced application path does notreside on the system:

<Apr 12, 2009 6:42:06 PM EDT> <INFO> <Upgrade> <BEA-800000> <An invalidpath, 'C:\bea\wlserver_10.3\user_projects\mydomain\medrecEar.ear', wasspecified for application, 'medrecEar'.>

You can ignore this message.

• If you upgraded the Avitek Medical Records application from version 8.1 to12.1.3 on a Solaris computer (only), before starting the server, you must edit thesetDomainEnv.sh file to remove -Xverify:none from the start command. Toremove the -Xverify:none, set JAVA_OPTIONS="" after the following line:

. ${WL_HOME}/common/bin/commEnv.sh

Otherwise, the server start fails with a JVM error.

Chapter 3Important Notes About the Domain Upgrade Process

3-14

Completing Post-Upgrade TasksAfter you upgrade the application environment, it may be necessary to performtasks such re-applying customizations to startup scripts, verifying file permissions andremote server startup options, and more.

This section includes the following topics:

• Re-apply Customizations to Startup Scripts

• Verify File Permissions

• Verify Remote Server Startup Options

• Recreating the Windows Node Manager Service

• Promote the Application Environment to Production

Not all these steps are required for all situations. Review the sections to determinewhich, if any, of these steps are appropriate for your environment. In addition, youshould review the compatibility issues in WebLogic Server 14.1.1.0.0 Compatibilitywith Previous Releases to determine if any of the compatibility issues apply to yourenvironment.

Re-apply Customizations to Startup ScriptsTo complete the upgrade of your application environment to 14.1.1.0.0, it might benecessary to re-apply any customizations to startup scripts. The following sectionsdescribe how to customize the default startup scripts as well as any custom startupscripts.

Default Startup ScriptsThe Reconfiguration Wizard does not carry forward any customizations that havebeen made to the default startup scripts, such as the setting of the JAVA_OPTIONSenvironment variable. After the upgrade process is complete, you must customize thedefault scripts again.

If you are upgrading your domain to 14.1.1.0.0 and you want to continue usingPointBase, you must add the PointBase JAR files to the beginning of the CLASSPATHenvironment variable definition. To do so, update the set CLASSPATH statement in yoursetDomainEnv files.

Note:

WebLogic Server 14.1.1.0.0 supports PointBase 5.7. However, the use ofany version of PointBase with WebLogic Server 10.3.3 or later requires aPointBase license, available at http://www.pointbase.com.

Custom Startup ScriptsTo update custom startup scripts:

Chapter 3Completing Post-Upgrade Tasks

3-15

• Set the JDK version to the JDK that you are using with WebLogic Server.

• Update the CLASSPATH variable, as follows:

– Add WebLogic Server 14.1.1.0.0 classes to the beginning of the variable.

– Remove all unused WebLogic classes prior to version 10.3.

– To continue using PointBase, include the PointBase database JARs at thebeginning of the CLASSPATH environment variable definition.

To know about upgrading a domain that uses an evaluation database, seeUpgrading a Domain that Uses an Evaluation Database.

Verify File PermissionsVerify the file permissions, as follows:

• If you backed up the domain directory as part of the upgrade, you must make yourbackup files secure because they might contain confidential information.

• During the upgrade process, file permissions are not preserved. If nondefault filepermissions are set on files, they must be verified and reset.

• On a UNIX system, ownership and permissions for any new files created duringthe upgrade process are assigned to the user performing the upgrade. Forexample, if the upgrade is performed by root, then root is assigned ownershipof any new files. As a result, any user who subsequently wants to update thesefiles in the domain must have root privileges. You may want to review or modify thepermissions on files created during the upgrade process.

Verify Remote Server Startup OptionsWhen you start the Administration Server, verify that the remote server startoptions, such as JAVA_HOME, BEA_HOME, and CLASSPATH, reference the WebLogicServer installation on the target Managed Server. This can be accomplished usingthe WebLogic Server Administration Console, as described in Configure startuparguments for Managed Servers in Oracle WebLogic Server Administration ConsoleOnline Help.

Note:

If the remote server startup options are not set correctly, when attemptingto start a Managed Server using Node Manager, messages similar to thefollowing may be written to the log file. Because these messages may besent recursively, they may eventually consume all space available on thedrive.

No config.xml was found.

Would you like the server to create a default configuration and boot? (y/n): java.io.IOException: The handle is invalid

Chapter 3Completing Post-Upgrade Tasks

3-16

Recreating the Windows Node Manager ServiceOn Windows systems, if you were running Node Manager as a Windows service foryour domain, you must reconfigure it if you want to continue using it.

For information about how to configure the Node Manager service for Windows,see Default Node Manager Configuration in Administering Node Manager for OracleWebLogic Server.

Optionally, you can remove the Node Manager service from your installation byrunning uninstallNodeMgrSrv.cmd. See Default Node Manager Configuration inAdministering Node Manager for Oracle WebLogic Server.

Promote the Application Environment to ProductionExecute standard procedures for quality assurance and performance tuning beforepromoting an application environment to production. You should test the executionof your applications (including external client applications) in your test applicationenvironment. If your applications use APIs that have been deprecated or removed,then you may encounter warnings or exceptions at run time. If you do, you can makeany required modifications before promoting your applications to production.

When all test criteria have been met, you can promote the application environment toproduction, as outlined in your upgrade plan (defined previously in Step 4: Create anUpgrade Plan).

When the new 14.1.1.0.0 application environment is deployed into production, youcan start redirecting requests to the new environment from the existing environment.Gradually, you can bring the existing environment to a safe state for shutdown. Thismight be accomplished using a load balancer, for example.

Enabling Edition-based Redefinition for Standalone WebLogic ServerInstallations (Optional)

Edition-based redefinition (EBR) provides standalone Oracle WebLogic Server userswith online upgrade support with uninterrupted availability.

If you want to perform a zero downtime upgrade when upgrading to a futurestandalone release of Oracle WebLogic Server, you must perform the following tasksafter installing and configuring the WebLogic domain.

Note:

For information about using EBR to perform an online application upgrade,see Using EBR to Upgrade an Application.

Before you begin, review the following prerequisites and pertinent information:

• Oracle database is the only EBR-supported database.

• In order to EBR-enable Weblogic Server for zero downtime upgrades, you mustuse the following database tables for storing system schemas: diagnostic logs,

Chapter 3Completing Post-Upgrade Tasks

3-17

timers, leasing tables, servlet sessions, persistent stores, WAN persistent stores,LLR tables, and batch data tables.

• The steps in this guide apply to Oracle WebLogic Server standalone installations.

• In cases where the Oracle WebLogic Server administrator is not able toperform privileged database operations, a database administrator must executeSQL statements or provide an environment for the Oracle WebLogic Serveradministrator to use.

• The Oracle WebLogic Server administrator or database administrator must createall editions.

• Enabling EBR requires downtime during the initial setup, but once the environmentis EBR-enabled, additional downtime is unlikely.

Stop the WebLogic Server DomainBefore you begin EBR-enabling your environment, you must first stop the WebLogicServer domain.

See Starting and Stopping Servers in Administering Server Startup and Shutdown forOracle WebLogic Server.

Create an Edition-enabled User and the EditionCreate an edition-enabled user before creating the edition on the database.

The WebLogic Server administrator or the database administrator must complete thefollowing:

1. Connect to SQL*Plus and execute the following commands to create an edition-enabled user:

$ sqlplus <sysdba-connection-string>

SQL> CREATE USER <username> identified by <password>

SQL> ALTER USER <username> ENABLE EDITIONS;

2. While still connected to SQL*Plus, execute the following commands to create theedition:

SQL> CREATE EDITION sample_ed;

SQL> GRANT USE ON sample_ed TO <username>;

3. If the edition-enabled user is going to rename tables and create views, then thefollowing permissions must be granted:

GRANT CREATE SESSION, CREATE TABLE, CREATE SEQUENCE, CREATE VIEW, CREATE PROCEDURE, CREATE TRIGGER TO <username>;

Chapter 3Completing Post-Upgrade Tasks

3-18

Run the WebLogic Services Upgrade ScriptsUse SQL*Plus to run the packaged EBR scripts from the WebLogic Services directory.These scripts upgrade the existing WebLogic Server system tables in the databasefrom non-EBR to EBR-enabled.

Use SQL*Plus to connect and execute the following commands to upgrade theexisting WebLogic Server database tables. Make sure that you are connecting withthe edition-enabled user. Note that the scripts are located in multiple directores andare part of the WebLogic Server standalone installation.

1. Connect to SQL*Plus and run the following scripts to create the tables.

$ sqlplus <user-connection-string>

SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/oracle_ebr/upgrade_js_ddl.sql -- rename/cover WEBLOGIC_TIMERSSQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/diagnostics/oracle_ebr/upgrade_wls_events_ddl.sql -- rename/cover VIEW WLS_EVENTSSQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/diagnostics/oracle_ebr/upgrade_wls_hvst_ddl.sql -- rename/cover WLS_HVSTSQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/oracle_ebr/upgrade_lstbs.sql -- rename/cover ACTIVESQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_checkpoint_data_ddl.sql -- rename/cover CHECKPOINTDATASQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_execution_instance_data_ddl.sql -- rename/cover EXECUTIONINSTANCEDATASQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_job_instance_data_ddl.sql -- rename/cover JOBINSTANCEDATASQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_job_status_ddl.sql -- rename/cover JOBSTATUSSQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_step_execution_instance_data_ddl.sql -- rename/cover STEPEXECUTIONINSTANCEDATASQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_step_status_ddl.sql -- rename/cover STEPSTATUSSQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/servletsess/oracle_ebr/upgrade.sql -- rename/cover WL_SERVLET_SESSIONSSQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/wanpersist/oracle_ebr/upgrade.sql -- rename/cover WLS_WAN_PERSISTENCE_TABLE

2. Verify that all of the tables have been EBR-enabled before continuing to the nextstep.

Chapter 3Completing Post-Upgrade Tasks

3-19

Run the Create Table ScriptsUse SQL*Plus to run the packaged EBR scripts from the WebLogic Services directory.These scripts will create the required tables and EBR-enable them automatically.

The WebLogic Server administrator or the database administrator must run the scripts.If you created these tables in a previous release, run the scripts again to ensure youhave the latest changes. The scripts will rename the exisiting tables, or, if needed,create new tables with an underscore, and then create the editioning views.

1. Connect to SQL*Plus and execute the following commands to create the tables.Note that the scripts are located in multiple directores.

Make sure that you are connecting as the edition-enabled user.

$ sqlplus <user-connection-string> SQL> ALTER SESSION SET EDITION = sample_ed;SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/oracle_ebr/crejstbs.sql -- creates WEBLOGIC_TIMERSSQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/oracle_ebr/crelstbs.sql -- creates ACTIVESQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/jbatch.sql -- creates JOBINSTANCEDATA, EXECUTIONINSTANCEDATA, STEPEXECUTIONINSTANCEDATA, JOBSTATUS, STEPSTATUS, CHECKPOINTDATASQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/diagnostics/oracle_ebr/wls_events_ddl.sql -- creates WLS_EVENTSSQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/diagnostics/oracle_ebr/wls_hvst_ddl.sql -- creates WLS_HVSTSQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/servletsess/oracle_ebr/create.sql -- creates WL_SERVLET_SESSIONSSQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/wanpersist/oracle_ebr/create.sql -- creates WLS_WAN_PERSISTENCE_TABLE

2. Verify that all of the tables have been created before continuing to the next step.

Set the New Edition as the DefaultOnce you have verified that all of the tables have been created and the new edition isworking as expected, set it as the default edition.

1. The WLS administrator or DBA will then make the new edition the default.

SQL> ALTER DATABASE DEFAULT EDITION = sample_ed;

2. If the data source is to specify the edition explicitly, then use WLST to set it.

$ wlst

wlst> readDomain('/path/to/domain')wlst> cd('/JDBCSystemResource/my-ds/JdbcResource/my-ds/JDBCDriverParams/NO_NAME_0/Properties/NO_NAME_0/Property/oracle.jdbc.editionName')

Chapter 3Completing Post-Upgrade Tasks

3-20

wlst> cmo.setValue('SAMPLE_ED')wlst> updateDomain()

Restart the WebLogic Server DomainAfter you have created the system tables, restart the WebLogic domain.

See Starting and Stopping Servers in Administering Server Startup and Shutdown forOracle WebLogic Server.

Upgrading a Domain that Uses an Evaluation DatabaseThe evaluation database is provided for use by the sample applications and codeexamples and may be used as a demonstration database. As of WebLogic 10.3.3, theevaluation database that is available from the installation program is changed fromPointBase to Derby.

If you are upgrading an examples or demonstration domain that was originally basedon PointBase, you have the option to continue using PointBase in the domain.

To continue using PointBase as the database for a domain being upgraded toWebLogic Server 14.1.1.0.0, complete the following steps:

1. When installing WebLogic Server 14.1.1.0.0 as described in Prepare for theUpgrade, you must use the full installer. The full installer does not preserve thePointBase installation from the previous WebLogic Server installation.

2. Complete the steps described in Upgrade Your Application Environment andCompleting Post-Upgrade Tasks.

The domain's configuration settings for PointBase are preserved.

3. Obtain a PointBase license, available from http://www.pointbase.com.

4. Restore your PointBase installation. PointBase is installed in the WL_HOME/common/eval/pointbase directory.

5. Add the PointBase database JARs at the beginning of the CLASSPATHenvironment variable definition.

Chapter 3Upgrading a Domain that Uses an Evaluation Database

3-21

4Upgrading WebLogic Web Services

Learn the procedures for upgrading WebLogic and RESTful Web services from OracleWebLogic Server 10.x to 12.2.x . Also, learn how to upgrade 8.1 WebLogic Webservices to 12.2.x WebLogic JAX-WS Web services.This chapter includes the following sections:

• Upgrading a 10.3.x RESTful Web Service (JAX-RS) to 12.2.x

• Upgrading a 10.x WebLogic Web Service (JAX-WS) to 12.2.x

• Upgrading an 8.1 WebLogic Web Service to the WebLogic JAX-WS Stack

• Upgrading a WebLogic JAX-RPC Web Service to the WebLogic JAX-WS Stack

Note:

10.3.x WebLogic Web services (JAX-WS or JAX-RPC) will continue to run,without any changes, on version 12.2.x of WebLogic Server because theassociated Web services run time is still supported in this release, althoughthey are deprecated and will be removed from the product in future releases.For this reason, Oracle highly recommends that you follow the instructions inthis chapter to upgrade your 10.3.x Web services to 12.2.x.

The JAX-RPC API has been deprecated in 12.2.x and will be removed ina future release. Oracle does not recommend upgrading to the JAX-RPCstack.

Upgrading a 10.3.x RESTful Web Service (JAX-RS) to12.2.x

In 10.3.x, a set of pre-built shared libraries were delivered with WebLogic Serverto support Jersey 1.9 and 1.1.5.1 Java API for RESTful Web Services (JAX-RS)Reference Implementations (RIs). In 12.2.x, WebLogic Server supports Jersey 2.21.x(JAX-RS 2.0 RI) by default.To use the pre-built shared libraries of 10.3.x, you neededto register them with the WebLogic Server instance, and modify the web.xml andweblogic.xml deployment descriptors to use the Jersey servlet and reference theshared libraries, respectively.In 12.2.x, as WebLogic Server supports Jersey 2.21.x (JAX-RS 2.0 RI) by default,registration as a shared library with WebLogic Server is no longer required.

To use the Jersey 2.21.x (JAX-RS 2.0 RI), you need to modify your 10.3.x RESTfulWeb service applications as follows:

1. Update your application deployment descriptors to reference the Jersey 2.xcontainer. See Servlet-based Deployment in Jersey 2.21 User Guide.

4-1

Note:

For backward compatibility, references tocom.sun.jersey.spi.container.servlet.ServletContainer,as shown in the following example, continues to work. However, Oraclerecommends that you update your application deployment descriptors toreference the Jersey 2.x container instead.

For example, replacecom.sun.jersey.spi.container.servlet.ServletContainer withorg.glassfish.jersey.servlet.ServletContainer in the following <web-app>content:

<web-app> <servlet> <display-name>My Jersey Application</display-name> <servlet-name>MyJerseyApp</servlet-name> <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class> <init-param> <param-name>javax.ws.rs.Application</param-name> <param-value>myPackage.myJerseyApplication</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>MyJerseyApp</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping></web-app>

For more advanced configuration options, see Jersey 2.21.1 User Guide.

2. If applicable, update all applications that use Jersey 1.x server APIs to use thecorresponding standard JAX-RS 2.0 or Jersey 2.x APIs instead. Support for theJersey 1.x (JAX-RS 1.1 RI) server APIs has been removed in this release andapplications that reference them will not work.

3. Update your clients to use the javax.ws.rs.client API, as described inDeveloping RESTful Web Service Clients in Developing and Securing RESTfulWeb Services for Oracle WebLogic Server.

Chapter 4Upgrading a 10.3.x RESTful Web Service (JAX-RS) to 12.2.x

4-2

Note:

Support for the Jersey 1.18 client packages, includingthe com.sun.jerseypackage, its nested packages, and theweblogic.jaxrs.api.client package, is deprecated in this releaseof WebLogic Server, but are maintained for backward compatibility.However, many Fusion Middleware components, such as Oracle WebServices Manager, have been migrated to the standard JAX-RS 2.0client API and are not compatible with the Jersey 1.x JAX-RS clientAPIs. Therefore, Oracle strongly recommends that you update yourRESTful client applications as soon as possible to use the standardJAX-RS 2.0 API.

The Jersey 1.x JAX-RS RI client APIs are not compatible with Jersey 2.x(JAX-RS 2.0 RI).

Upgrading a 10.x WebLogic Web Service (JAX-WS) to12.2.x

No steps are required to upgrade a 10.x WebLogic Web service to 12.2.x. You canredeploy the JAX-WS Web service to WebLogic Server 12.2.x without making anychanges or recompiling.

Upgrading an 8.1 WebLogic Web Service to the WebLogicJAX-WS Stack

The 8.1 WebLogic Web services runtime was removed in the 12.1.2 release. If you areusing 8.1 WebLogic Web services, you must upgrade the 8.1 WebLogic Web serviceapplications to the JAX-WS (Java API for XML-Based Web Services) stack. The 8.1WebLogic Web services rely on Apache XMLBeans for mapping XML elements inSOAP payloads into Java objects and vice versa. XMLBeans are not supported in12.1.2 and later.

Note:

Upgrade 8.1 Web service to JAX-WS on your WebLogic Server releasebefore you upgrade to 14.1.1.0.0. After you upgrade to 14.1.1.0.0, your 8.1Web services will no longer work.

Upgrading to the JAX-WS stack allows you to take advantage of the latesttechnologies and standards support in WebLogic Server. This path requires a manualupgrade process, and the level of effort depends on the nature of the existing 8.1Web service applications. For example, if the applications have little XMLBeans usage,then the upgrade process is relatively easy. For 8.1 Web Service applications withheavy XMLBeans dependencies, you must modify the business logic in the serviceimplementation to use JAXB classes instead of XMLBeans classes. JAX-WS does

Chapter 4Upgrading a 10.x WebLogic Web Service (JAX-WS) to 12.2.x

4-3

not support RPC-encoded style. The 8.1 Web Service applications with RPC-encodedstyle must adopt more interoperable literal style service contracts.

The WebLogic JAX-WS runtime is based on the JAX-WS 2.2 specification and theWeb Services for Java EE v1.3 (JSR 109) specifications. These define annotationsthat are used in a Java Web Service (JWS) source file to define a Web service.Ant tasks are then used to compile the JWS into a Java class and generate all theassociated artifacts. The Java Web Service (JWS) is the core of your JAX-WS webservice.

Upgrading your 8.1 Web service includes the following high-level tasks:

• Upgrade any Web service EJBs from 2.x to 3.x.

JAX-WS supports EJB 3.0 and 3.x. It does not support EJB 2.x.

• Rewrite the 8.1 Web service class as a JAX-WS JWS file and map any proprietary8.x features to similar JAX-WS features.

There is not a one-to-one correspondence between 8.1 Web service features andJAX-WS 12.1.x features.

• Update the Ant build script that builds the Web service to call the 12.1.x WebLogicWeb service Ant task jwsc instead of the 8.1 servicegen task.

• Generate new JAX-WS clients using the JAX-WS clientgen Ant task.

JAX-WS Upgrade Considerations

Before upgrading to JAX-WS, consider the following:

• The JAX-WS specification supports the document-literal and rpc-literal styles, butnot rpc-encoded.

• The JAX-WS specification does not support SOAP Arrays.

See Developing JAX-WS Web Services for Oracle WebLogic Server.

Upgrading a WebLogic JAX-RPC Web Service to theWebLogic JAX-WS Stack

The WebLogic JAX-WS run time is based on the JAX-WS (The Java API for XML-Based Web Services) 2.2 specification and the Web Services for Java EE v1.3 (JSR109) specifications. Starting with JAX-WS 2.0, the JAX-WS technology has replacedJAX-RPC in the Java Platform and in WebLogic Server. JAX-RPC Web Services inWebLogic applications should be upgraded to JAX-WS.

This section summarizes how to upgrade a WebLogic JAX-RPC Web service to usethe WebLogic JAX-WS stack.

Upgrading your WebLogic Server JAX-RPC Web service includes the following high-level tasks:

• Upgrade any Web service EJBs from 2.x to 3.x.

JAX-WS supports EJB 3.0 and 3.x. It does not support EJB 2.x.

• Upgrade your JWS, mapping any proprietary JAX-RPC features to similar JAX-WSfeatures.

Chapter 4Upgrading a WebLogic JAX-RPC Web Service to the WebLogic JAX-WS Stack

4-4

Note that there is not a one-to-one correspondence between WebLogic JAX-RPCWeb service features and JAX-WS 12.x features.

• Update the Ant build script that builds the Web service to change the value of thetype attribute on the jws, wsdlc, and clientgen tasks to be "JAXWS" (for example,type="JAXWS").

• Generate new JAX-WS clients using the JAX-WS clientgen Ant task.

JAX-WS Upgrade Considerations

When upgrading to JAX-WS, you should consider the following:

• The JAX-WS specification supports the document-literal and rpc-literal styles, butnot rpc-encoded.

• SOAP Arrays are not supported by JAX-WS.

See Developing JAX-WS Web Services for Oracle WebLogic Server

Chapter 4Upgrading a WebLogic JAX-RPC Web Service to the WebLogic JAX-WS Stack

4-5

AWebLogic Server 14.1.1.0.0 Compatibilitywith Previous Releases

Learn about important compatibility information that you should consider beforeupgrading to Oracle WebLogic Server 14.1.1.0.0 from 10.3.x, 12.1.x, or 12.2.1.xrelease. Also learn about the feature changes in various Oracle WebLogic Serverversions that may impact the applications you plan to run in the upgradedenvironment.See also:

• WebLogic Server Compatibility in Understanding Oracle WebLogic Server. Thissection provides general information about WebLogic Server compatibility goalsand how they apply to this WebLogic Server release.

• What's New in Oracle WebLogic Server 14.1.1.0.0 for this and prior releases.These documents provide information about new features that are available to youas well as behavior changes that may impact your applications.

Compatibility considerations are provided in the following sections. The sections thatapply to your situation depend on the WebLogic Server version from which you areupgrading to WebLogic Server 14.1.1.0.0. See Table A-1for a list of sections to whichyou should refer based on your current WebLogic Server version.

Table A-1 Sections Applying to Upgrades From Each WebLogic Server Version

If You Are UpgradingFrom This WebLogicServer Version

Refer to These Sections

12.2.1.4.0 Java EE 8 Support

Compatibility Changes When Migrating From JDK 8 to JDK 11

Upgraded Version of Jython

Removed WebLogic Server Multitenant Functionality and ResourceConsumption Management

Removed WebLogic Full and IIOP-Based Clients

Components and Features Removed in WebLogic Server 14.1.1.0.0

12.2.1.3.0 All sections in the above row, plus:

About WebLogic Server Cluster Messaging

12.2.1.0.0 All sections in the above row, plus:

Upgraded Version of Apache Ant

Removed the Option to Limit Run-Time Footprint When StartingWebLogic Server

12.1.3 All sections in the above row, plus:

Random Number Generator

Automatic Binding of the Default CommonJ Work Manager Has BeenRemoved

Parallel Deployment

A-1

Table A-1 (Cont.) Sections Applying to Upgrades From Each WebLogic ServerVersion

If You Are UpgradingFrom This WebLogicServer Version

Refer to These Sections

12.1.2 All sections in the above row, plus:

Server Logging Bridge

Oracle Database Drivers

Oracle Enable JavaNet FastPath

12.1.1 All sections in the above rows, plus:

Maximum POST Size

WLDF Schema Upgrade

jdbc-connection-timeout-secs Element Has Been Removed

Commitment of Local Transactions

10.3.5 and 10.3.6 All sections in the above rows, plus:

JVM Settings

Node Manager startScriptEnabled Default Value

Enterprise Java Beans (EJBs)

WebLogic Server 8.1 Web Services Stack Has Been Removed

Universal Description and Discover (UDDI) Registry Has BeenRemoved

Certicom SSL Implementation Has Been Removed

Oracle Coherence Version

Deprecated and Obsolete Web Application Features

Evaluation Database Changed From PointBase to Derby

DataSource Profile Logging

ONS Debugging

Oracle Type 4 JDBC Drivers From DataDirect

Default Message Mode Has Changed

10.3.3 and 10.3.4 All sections in the above rows, plus:

Modifications to SSLMBean

10.3.2 All sections in the above rows, plus:

New Web Services Features

Introduction of JSSE

Performance Enhancements for Security Policy Deployment

ActiveCache

Class Caching

Deprecated JDBC Drivers

Changes to weblogic.jms.extension API

Persistent Store Updates

10.3.1 All sections in the above rows, plus:

Oracle Internet Directory and Oracle Virtual Directory AuthenticationProviders

Appendix A

A-2

Table A-1 (Cont.) Sections Applying to Upgrades From Each WebLogic ServerVersion

If You Are UpgradingFrom This WebLogicServer Version

Refer to These Sections

10.3.0 All sections in the above rows, plus:

CapacityIncrement Attribute

Middleware Home Directory

Resource Registration Name

Servlet Path Mapping

Java EE 8 SupportOracle WebLogic Server 14c (14.1.1.0.0) is a fully compatible implementation of theJava Platform, Enterprise Edition (Java EE) Version 8.0.

For more information, see Java EE 8 Support in What's New in Oracle WebLogicServer.

Compatibility Changes When Migrating From JDK 8 to JDK11

There are many upward compatibility changes when migrating from JDK8 to JDK11,and hence may require application changes.

Review the following changes where applications may be affected:

• The deprecated APIs, sun.misc.*, sun.reflect.*, java.awt.peer, JavadocAPI’s, xerces, Resource Consumption Management (RCM), and Sockets DirectProtocol (SDP) are removed in Java SE 11. In some cases, this change mayrequire some major redesign of code that depends on these features.

• There is an adoption of new third party jar files that are compatible with JDK11.Some of these changes are not upward compatible.

• The rt.jar, tools.jar, and the Java Runtime Environment (JRE) no longer exist.

• The Java Flight Recorder (JFR) API is re-written completely in Java SE 11.

• You cannot use setAccessible to get private methods or fields of JDK classes.There are a few jar files that continue to break into JDK classes, throwing thefollowing warning:

WARNING: An illegal reflective access operation has occurred

This warning can be ignored.

• There are class version and format changes in Java SE 11. Therefore, code thatreads and writes classes may need to be modified.

• There is a new Java version string scheme in Java SE 11.

Appendix AJava EE 8 Support

A-3

• The following Java EE classes that were in the Java SE runtime have beenremoved in Java SE 11:

– JAXB

– JAX-WS/JWS/SOAP

– JTA

– Activation Framework

– JSR 250 common annotation

– CORBA

New jar files have been added to the classpath to account for this.

• Major security changes in Java SE 11 include:

– The default keystore type is changed to PKCS12.

– The security files are moved from JAVA_HOME/jre/lib/security/java.security to JAVA_HOME/conf/security/java.security.

– The security policy file on JDK8 does not support new jrt file system.Therefore, it is difficult to have a single file for JDK8 and JDK8+.

• The command line options like -Xbootclasspath/p, commercial, -d64, memoryoptions, garbage collection options, endorsed standards, extension directory, and-source/target are fatal.

• All WebLogic Server jar files are intended to coexist with the JDK11 modulesystem. However, the jar files continue to be on the classpath instead of themodule path, which means that all jar files are part of the unnamed module.

• The application and platform class loaders are no longer instances ofthe java.net.URLClassLoader class. Code that depends on this to extendclassloaders will no longer work.

For more information about the significant changes in JDK 11 and the migrationprocess, see Oracle JDK Migration Guide.

Upgraded Version of JythonThe WebLogic Scripting Tool (WLST) in Oracle WebLogic Server uses Jython. InOracle WebLogic Server 14.1.1.0.0, the Jython version has been upgraded from 2.2.1to 2.7.1. WLST users will benefit from the enhanced functionality in this version ofJython.

After you upgrade to Oracle WebLogic Server 14.1.1.0.0 and before you create the14.1.1.0.0 domains using WLST scripts, review the issues caused by the Jythonversion upgrade and their respective workarounds as described in Behavior Changesin Jython version 2.7 in Release Notes for Oracle WebLogic Server.

Removed WebLogic Server Multitenant Functionality andResource Consumption Management

WebLogic Server Multitenant domain partitions, resource groups, resource grouptemplates, virtual targets, resource override configuration MBeans, and Resource

Appendix AUpgraded Version of Jython

A-4

Consumption Management have been removed from WebLogic Server as of version14.1.1.0.0.

Before upgrading to WebLogic Server 14c, domains using partitions, server groups,server group templates, virtual targets, and resource consumption management musthave these entities removed. Oracle recommends the use of Docker and Kubernetescontainers.

For more information, see WebLogic Server Multitenant Functionality and ResourceConsumption Management in What's New in Oracle WebLogic Server.

Removed WebLogic Full and IIOP-Based ClientsThe following WebLogic clients have been removed from WebLogic Server as ofversion 14.1.1.0.0:

• The WebLogic Full client (wlfullclient.jar) and its associated WebLogicJarBuilder Tool (wljarbuilder.jar).

• IIOP-based thin clients, including wlclient.jar, and the clients that depend on it.

• IIOP-based Java SE JDK clients (Java clients that use IIOP without any WebLogicJARs in their class path).

For the complete list of removed clients and for more information about the alternativeclients that can be used, see WebLogic Full and IIOP-Based Client in What's New inOracle WebLogic Server.

Components and Features Removed in WebLogic Server14.1.1.0.0

The following components and features are removed from WebLogic Server as ofversion 14.1.1.0.0:

• EJBGen, an Enterprise JavaBeans 2.x code generator utilityThe use of EJB 3.0 no longer requires all of the code generation that EJBGenprovided.

• WebLogic JMS Resource Adapter

• Oracle Traffic Director (OTD)

• Compatibility Setting for JTA Security Interoperability Mode

• JMS Interop Modules

• Administration Console Extensibility

Due to the removal of these components and features, you may have to makenecessary changes to the application code or configuration before upgrading toWebLogic Server 14.1.1.0.0. For more information, see Removed Functionality andComponents in What's New in Oracle WebLogic Server.

About WebLogic Server Cluster Messaging

Appendix ARemoved WebLogic Full and IIOP-Based Clients

A-5

In 12.2.1.4.0, WebLogic Server cluster messaging was enhanced. If all of the serversin a cluster are running the same installation version of WebLogic Server, no changesare required.

When you perform a rolling upgrade from 12.2.1.3.0 to 12.2.1.4.0 or a downgradefrom 12.2.1.4.0 to 12.2.1.3.0, the newer 12.2.1.4.0 servers must be explicitly set,to temporarily allow the older protocol. You can do this by setting the systemproperty weblogic.upgradeExpirationDate with an expiration date, which enables the12.2.1.4.0 server to allow communication on the cluster until that expiration date andtime is reached. For example:

-Dweblogic.upgradeExpirationDate=2020-01-05T08:47

If you want the clusters that are at different versions, to continue to communicate foran extended period of time, you must set the value to a preferred future upgrade date.

Note:

The system property -Dweblogic.upgradeExpirationDate must be usedin the Server Start arguments for each of the Managed Servers, andnot in the JAVA_OPTIONS environment variable in the startWebLogic.sh orstartWebLogic.cmd scripts.

Upgraded Version of Apache AntOracle WebLogic Server 12.2.1.3.0 includes Apache Ant 1.9.8, which may have animpact on the use of the clientgen Ant task. The clientgen Ant task generates, froman existing WSDL file, the client component files that client applications use to invokeboth WebLogic and non-WebLogic web services. Note the following when using the<binding> child element of this Ant task:

• You use the <binding> element the same way as the standard Ant FileSet datatype, using the same attributes.

• In Apache Ant 1.9.8, the Ant FileSet data type is changed so that it may specifyeither a single file, or a single directory. Therefore, if you use the <binding>element to specify multiple files or directories, the clientgen Ant task might fail.

For more information about specifying the <binding> child element, see binding inWebLogic Web Services Reference for Oracle WebLogic Server.

Removed the Option to Limit Run-Time Footprint WhenStarting WebLogic Server

When you start a WebLogic Server instance, all services are started including EJB,JMS, Connector, Clustering, Deployment, Management, and so forth. WebLogicServer provides a startup option that you can use to run the lighter weight run-timeinstance in any WebLogic domain.

This startup mode can result in quicker startup times for WebLogic Server and asmaller resource footprint on the host machine. You can start a lighter weight run-timeinstance by specifying the following weblogic.Server command option:

Appendix AUpgraded Version of Apache Ant

A-6

java weblogic.Server -DserverType= {"wlx" | "wls"}

As of Oracle WebLogic Server version 12.2.1.0.0, this startup option is removed.

Random Number GeneratorOracle WebLogic Server 14.1.1.0.0 uses a more secure random number generatoralgorithm than in previous releases. This can result in slow startup of ManagedServers, Configuration Wizard, Node Manager, and WebLogic Java utilities such asutils.ImportPrivateKey on low-entropy systems. Therefore, you should take steps toincrease system entropy.

On UNIX systems, you use rng-tools to replace system entropy. To configure it,edit /etc/sysconfig/rngd and add the following line:

EXTRAOPTIONS="-i -r /dev/urandom -o /dev/random -b"

You can also use the -t 60 and -W 2048 parameters. These parameters add bits tothe entropy pool every 60 seconds until the pool reaches the size of 2048.

Use the following command to generate entropy manually:

rngd -r /dev/urandom -o /dev/random -b

Use the following command to check current entropy:

cat /proc/sys/kernel/random/entropy_avail

Automatic Binding of the Default CommonJ Work ManagerHas Been Removed

The Work Manager API, commonj.work, provides a set of interfaces that allows anapplication to execute multiple work items concurrently within a container. Automaticbinding of the default CommonJ Work Manager to java:comp/env/wm/default wasremoved in WebLogic Server 12.2.1 because it was not in compliance with the JavaEE 7 platform specification.

If you have an application that attempts to use the default CommonJ Work Manager,you can do either of the following:

• Add a resource-ref entry for wm/default in a deployment descriptor. For example:

<resource-ref> <res-ref-name>wm/default</res-ref-name> <res-type>commonj.work.WorkManager</res-type> <res-auth>Container</res-auth> </resource-ref>

• Have the CommonJ Work Manager injected into the application component. Forexample:

@Resource commonj.work.WorkManager myWorkManager;

Appendix ARandom Number Generator

A-7

Parallel DeploymentWebLogic Server 12.2.1 adds support for parallel deployment of applications andmodules, which improves startup and post-running deployment time.

By default, in WebLogic domains that are created with, or upgraded to, WebLogicServer 12.2.1 (or later):

• Parallel deployment of applications is enabled.

• Parallel deployment of modules for all applications in the domain is disabled.

In WebLogic Server 12.1.3 and earlier versions, applications are always deployedserially. The default deployment order is the natural order that is defined in the domainconfiguration (that is, as established in the config.xml file). However, in those earlierWebLogic Server releases, you can explicitly control deployment order by setting theDeploymentOrder attribute of the AppDeploymentMBean, using the WebLogic ServerAdministration Console or programmatically as explained in Changing the DeploymentOrder for Applications and Standalone Modules in Deploying Applications to OracleWebLogic Server. The use of this feature with older releases is important if specificdependencies exist between applications.

If you create a new domain in WebLogic Server 14.1.1.0.0, or upgrade an existingdomain to 14.1.1.0.0, you can restore the WebLogic Server 12.1.3 deployment orderbehavior by disabling the following attributes of the DomainMBean:

• ParallelDeployApplications: Determines whether applications are deployed inparallel. (This attribute is enabled by default.)

• ParallelDeployApplicationModules: Determines whether the modules ofapplications are deployed in parallel. (This attribute is disabled by default.)

However, disabling the preceding attributes prevents you from being able to takeadvantage of the significant performance benefits of parallel deployment. Instead ofdisabling parallel deployment altogether in the domain you are upgrading to WebLogicServer 14.1.1.0.0, Oracle recommends checking to see whether the deploymentordering of any applications or modules has been customized, and if so, whether itis necessary.

See:

• Enabling Parallel Deployment for Applications and Modules in DeployingApplications to Oracle WebLogic Server, which contains important considerationsregarding application and module dependencies when using parallel deployment.

• Change the server deployment order in Oracle WebLogic Server AdministrationConsole Online Help, which explains how to view or change the deployment orderof deployments using the WebLogic Server Administration Console.

Server Logging BridgeThe Server Logging Bridge provides a lightweight mechanism for applications thatcurrently use Java Logging or Log4J Logging to have their log messages redirected toWebLogic logging services. As of WebLogic Server 12.1.3, the Server Logging Bridgeis added to the root logger of the java.util.logging Logger tree when WebLogicServer starts. Therefore, you no longer need to explicitly configure the Server LoggingBridge.

Appendix AParallel Deployment

A-8

If you have configured the weblogic.logging.ServerLoggingHandler as described inServer Logging Bridge in Configuring Log Files and Filtering Log Messages for OracleWebLogic Server:

• If weblogic.logging.ServerLoggingHandler is attached to the root logger, Oraclestrongly recommends that you remove it from your logging.properties file.

• If weblogic.logging.ServerLoggingHandler is attached to a logger other thanthe root, Oracle strongly recommends that you either remove it from thelogging.properties configuration, or set the useParentHandlers attribute tofalse (for example, com.foo.barUseParentHandlers=false).

These situations also apply to Log4J. However, the terminology is different:

• weblogic.logging.log4j.ServerLoggingAppender is the bridge for Log4J.

• useParentHandlers is called Additivity in Log4J. It is configured aslog4j.additivity.com.foo.bar=false in the log4j.properties file.

Oracle Database DriversAs of release 12.1.2, WebLogic Server installation includes the Oracle Database 12cdrivers.

This requires the following changes to your applications:

• Replace references to wlserver/server/lib/ojdbc6.jar with ${MW_HOME}/oracle_common/modules/features/com.oracle.db.dbc7-no-dms.jar. Note that this is automatically included inthe class path when using weblogic.jar.

• Replace references to wlserver/server/lib/aqapi.jar with ${MW_HOME}/oracle_common/modules/oracle.jdbc_12.1.0/aqapi.jar, which alsorequires that you use com.oracle.db.jdbc7-no-dms.jar.

If you want to continue running with the Oracle Database 11g driver JARs, you must:

• add them to the front of the classpath

• move the Oracle Database 12c driver JARs out of the MW_HOME/oracle_common/modules/oracle.jdbc_12.1.0 directory.

Oracle Enable JavaNet FastPathOracle Enable JavaNet Fastpath enables the Oracle JDBC JavaNet Fastpath toreduce data copies and fragmentation. As of WebLogic Server 12.1.3, this attributeis no longer supported in the WebLogic Server Administration Console.

In previous versions of WebLogic Server, you could configure the Oracle EnableJavaNet FastPath attribute on the Configuration:Oracle tab in the WebLogicServer Administration Console. To go to the Configuration:Oracle tab, click DomainStructure, click Services, and then click Data Sources in the WebLogic ServerAdministration Console.

Appendix AOracle Database Drivers

A-9

Maximum POST SizeA new session descriptor, max-save-post-size, has been added in WebLogic Server12.1.2, which may impact existing applications. This descriptor sets the maximum size,in bytes, of the POST that is saved or buffered by the application container duringFORM authentication.

The default value of the max-save-post-size descriptor is 4096 bytes.

If your application posts a form for which the size exceeds 4096 bytes during FORMauthentication, you must increase max-save-post-size to an appropriate value.Otherwise, a MaxPostSizeExceededException occurs in the browser.

WLDF Schema UpgradeIf you are using a JDBC-based store for WebLogic Diagnostics Framework (WLDF)event and harvester data, you must update or recreate the WLDF tables in yourdatabase.

In the wls_events table, change the THREADNAME column from varchar(128) tovarchar(250). In the wls_hvst table, add the column WLDFMODULE varchar(250)default NULL.

This upgrade applies only to WebLogic Server standalone installations. Forinstallations that include Fusion Middleware products, the schema upgrade processis done through the Oracle Upgrade Assistant.

See Configuring a JDBC-Based Store in Configuring and Using the DiagnosticsFramework for Oracle WebLogic Server.

jdbc-connection-timeout-secs Element Has Been RemovedThe jdbc-connection-timeout-secs element in the weblogic.xml deploymentdescriptor has been removed in WebLogic Server 12.1.2. If your applicationconfigures the jdbc-connection-timeout-secs element, you must remove it from theweblogic.xml deployment descriptor to prevent deployment of the application fromfailing.

Commitment of Local TransactionsAs of WebLogic Server 12.1.2, local transactions on non-XA connections that werenot committed or rolled back by the application are now explicitly committed bydefault when the connection is returned to the pool. In addition, the following twoparameters have been added to set whether or not local transactions on non-XA andXA connections are committed when the connection pool is closed:

• -Dweblogic.datasource.endLocalTxOnNonXAConWithCommit=false can be usedto avoid one extra DBMS round-trip with non-XA connections, for applications thatare trusted to always complete their transaction explicitly. If this parameter is setto false, local transactions on non-XA connections are implicitly committed orrolled back when a connection pool is closed, according to what the particularJDBC driver being used does when setAutoCommit(true) is called. Per theJDBC specification, that action is to commit the transaction, but there is varied

Appendix AMaximum POST Size

A-10

compliance among drivers. By default, or if the property is set to true, thesetransactions are now committed.

• -Dweblogic.datasource.endLocalTXOnXAConWithCommit=true can be used tocommit local transactions on XA connections when a connection pool is closed.By default, these transactions are rolled back.

JVM SettingsThe Java virtual machine (JVM) is a virtual execution engine instance that executesthe bytecodes in Java class files on a microprocessor. How you tune your JVM affectsthe performance of WebLogic Server and your applications.

When upgrading a WebLogic Server 10.3.x domain to a WebLogic Server 14.1.1.0.0or a greater domain and when running on Java SE 8 (but not Java SE 11 or later), youmay have to manually set the location of the Java endorsed directory (or directories)for WebLogic Server (JRE_HOME/lib/endorsed).

Setting the Location of Java Endorsed Directory for WebLogic ServerIn the following situation, you do not need to manually set the location of the Javaendorsed directory (or directories) for WebLogic Server:

• You are using Oracle WebLogic Server 14.1.1.0.0 or greater domains whenrunning on Java SE 8 (but not Java SE 11 or later) and start scripts that weregenerated by domain creation via the WebLogic Server 14.1.1.0.0 or greaterConfiguration Wizard, or your start scripts reference setDomainEnv.cmd/sh asgenerated by domain creation via the WebLogic Server 14.1.1.0.0 or greaterConfiguration Wizard.

If none of these situations apply, and any one of the following situations apply, youmust manually set the location of the Java endorsed directory for WebLogic Server inthe command you use to start your Managed Servers:

• you are using custom start scripts, that is, start scripts that are not provided byOracle.

• you are trying to create an empty domain using java.weblogic.Server.

In any of these cases, include the java.endorsed.dirs parameter in the ManagedServer startup command.

startWeblogic.sh -Djava.endorsed.dirs=ORACLE_HOME/oracle_common/modules/endorsed

To specify multiple Java endorsed directories, separate each directory path with acolon (:).

Note:

In all of the options described in this section, you must replace ORACLE_HOMEwith the absolute path to your WebLogic Server installation.

Appendix AJVM Settings

A-11

You can also specify this value when calling startServer by passing the values asjvmArgs, or when calling nmstart by passing them as properties, such as:

wls:/nm/mydomain> prps = makePropertiesObject("Arguments=-Djava.endorsed.dirs=ORACLE_HOME/oracle_common/modules/endorsed")

wls:/nm/mydomain> nmStart("AdminServer",props=prps)

If you are using Node Manager to start the Managed Server, you can include the-Djava.endorsed.dirs=ORACLE_HOME/oracle_common/modules/endorsed") parameterin the ServerStartMBean's arguments attribute, either using WLST or the WebLogicServer Administration Console. If using the WebLogic Server Administration Console,enter this parameter in the Arguments field on the server's Configuration > ServerStart tab. This attribute will be applied when you call start(server_name 'Server')from a WLST client that is connected to the Administration Server or when you clickStart for the server in the WebLogic Server Administration Console.

Setting permgen spaceIf you receive an OutOfMemory: PermGen Space error when starting a Managed Server,you have to manually set the permgen space to at least 128M and increase themaximum permgen space to at least 256M.

Note:

In all of the options described here, you must replace WL_HOME with the fullpath to your WebLogic Server installation.

This can be done by specifying the following in the ServerStartMBean's argumentsattribute, using either WLST or the WebLogic Server Administration Console. Ifusing the WebLogic Server Administration Console, enter -XX:PermSize=128m -XX:MaxPermSize=256m in the Arguments field on the server's Configuration > ServerStart tab.

Note:

If you plan to start the server via the WebLogic Server AdministrationConsole, you must apply the permgen settings prior to starting the serverfrom the WebLogic Server Administration Console. Otherwise the server maygo into an unrecoverable state.

Appendix AJVM Settings

A-12

This attribute will be applied when you call start(server_name 'Server') from aWLST client that is connected to the Administration Server or when you click on theStart button for the server in the WebLogic Server Administration Console.

Another method you can use is to start the Managed Server via the command line andspecify the correct settings, as shown here:

• On UNIX: startManagedWebLogic.sh server_name -XX:PermSize=128m -XX:MaxPermSize=256m

• On Windows: startManagedWebLogic.cmd server_name -XX:PermSize=128m -XX:MaxPermSize=256m

Note:

You can use -XX:MaxPermSize=256m only when running on JDK6 or JDK7.

You can also specify these values when calling startServer by passing the values asjvmArgs, or when calling nmstart by passing them as properties, such as:

wls:/nm/mydomain> prps = makePropertiesObject("Arguments= -XX:PermSize=128m -XX:MaxPermSize=256m")

wls:/nm/mydomain> nmStart("AdminServer",props=prps)

Node Manager startScriptEnabled Default ValueAs of WebLogic Server 12.1.1, the default value for startScriptEnabled has beenchanged to true. In all previous releases, the default was false. If you do not want touse a start script with Node Manager, change this value to false after upgrading.

Enterprise Java Beans (EJBs)Oracle Kodo has been deprecated as of WebLogic Server 10.3.1. As of WebLogicServer 12.1.1, EclipseLink is the default JPA provider, replacing Kodo. Applicationsthat use Kodo as the persistence provider with WebLogic Server 12.1.2 must beupdated. See Updating Applications to Overcome Conflicts in Developing EnterpriseJavaBeans for Oracle WebLogic Server.As of WebLogic Server 12.1.1, support for JPA 2.0 is built in. JPA 2.0 includesimprovements and enhancements to domain modeling, object/relational mapping,EntityManager and Query interfaces, and the Java Persistence Query Language(JPQL), and more. See Using JPA 2.0 with TopLink in WebLogic Server in DevelopingEnterprise JavaBeans for Oracle WebLogic Server.

WebLogic Server 8.1 Web Services Stack Has BeenRemoved

In WebLogic Server 12.1.1 release, the WebLogic Server 8.1 Web services stack hasbeen removed. Therefore, WebLogic Server 8.1 Web services applications will nolonger work.

Appendix ANode Manager startScriptEnabled Default Value

A-13

Oracle recommends that you upgrade such applications to the WebLogic JAX-RPC orJAX-WS stacks, as described in Upgrading an 8.1 WebLogic Web Service to 12.1.x.

Universal Description and Discover (UDDI) Registry HasBeen Removed

In WebLogic Server 12.1.1 release, UDDI has been removed.

If you are still using UDDI and want to upgrade to WebLogic Server 12.1.1, Oraclerecommends that you migrate to the Oracle Service Registry (OSR). OSR UDDI 3.0compliant.

Certicom SSL Implementation Has Been RemovedIn WebLogic Server release 12.1.1, the Certicom SSL implementation has beenremoved.

This change may require you to update system properties and debug switches asdescribed in Command Line Properties for Enabling SSL Debugging and SystemProperty Differences Between the JSSE and Certicom SSL Implementations inAdministering Security for Oracle WebLogic Server.

Oracle Coherence VersionThe WebLogic Server 12.1.1 installer includes Coherence 3.7.1. All servers in a clustermust use the same version of Coherence. Therefore, all cache servers in the clustermust be upgraded to Coherence 3.7.1.

Deprecated and Obsolete Web Application FeaturesSee the list of Web application features that have been deprecated from, or are nolonger supported in, Oracle WebLogic Server 12.1.1.

• Information about deprecated functionality in Oracle WebLogic Server 11gRelease 1 can be found on My Oracle Support at https://support.oracle.com/.

In the Search Knowledge Base field, enter document ID 888028.1.

• Information about functionality that is deprecated in Oracle WebLogic Server12.1.1 can be found on My Oracle Support at https://support.oracle.com/.Search for Deprecated Features.

Evaluation Database Changed From PointBase to DerbyAs of WebLogic Server 10.3.3, the evaluation database available from the WebLogicServer installation program has been changed from PointBase to Apache Derby. Ifyou select the Evaluation Database option on the Choose Products and Componentsscreen, the Derby database is installed in the WL_HOME\common\derby directory. Ifyou select a Typical installation, Derby is installed by default.

If you have a domain based on PointBase and you want to continue usingPointBase after upgrading the domain to WebLogic Server 10.3.3 or later, you

Appendix AUniversal Description and Discover (UDDI) Registry Has Been Removed

A-14

must obtain a PointBase license from http://www.pointbase.com. Note that the fullWebLogic Server installer does not preserve the PointBase installation directory. As analternative to using PointBase, you can migrate the domain database to Derby.

See Upgrading a Domain that Uses an Evaluation Database.

DataSource Profile LoggingTo provide better usability and performance, Oracle WebLogic Server 10.3.6 andlater uses a data source profile log to store events. See Monitoring WebLogic JDBCResources in Administering JDBC Data Sources for Oracle WebLogic Server.

ONS DebuggingIn Oracle WebLogic Server version 10.3.6 and later, the package names for UCPand ONS are no longer repackaged. For information about how to set UCP and ONSdebugging, see Setting Debugging for UCP/ONS in Administering JDBC Data Sourcesfor Oracle WebLogic Server.

Oracle Type 4 JDBC Drivers From DataDirectAs of Oracle WebLogic Server 10.3.6, Oracle Type 4 JDBC drivers from DataDirectare referred to as WebLogic-branded DataDirect drivers. Oracle has removed thedocumentation in Oracle® Fusion Middleware Type 4 JDBC Drivers for OracleWebLogic Server and no longer provides detailed information about DataDirectdrivers. Oracle continues to provide information about how WebLogic-branded driversare configured and used in WebLogic Server environments at Using WebLogic-branded DataDirect Drivers in Developing JDBC Applications for Oracle WebLogicServer.Oracle recommends reviewing DataDirect documentation for detailed informationabout driver behavior. See Progress DataDirect for JDBC User's Guide Release5.1 and Progress DataDirect for JDBC Reference Release 5.1at http://www.datadirect.com/index.html.

Default Message Mode Has ChangedAs of WebLogic Server 12.1.1, the default messaging mode has been changedfrom multicast to unicast. When creating a new cluster, Oracle recommends the useof unicast for messaging within a cluster. For backward compatibility with previousversions of WebLogic Server, you must use multicast for communications betweenclusters.

Modifications to SSLMBeanAs of WebLogic Server 10.3.5, the SSLMBean has been modified to support additionalSSL configuration capabilities, including the ability to enable or disable the JSSEadapter. See the following topics:

• For a list of the differences in the way the JSSE SSL implementation handles theWebLogic system properties, see System Property Differences Between the JSSEand Certicom SSL Implementations in Administering Security for Oracle WebLogicServer.

Appendix ADataSource Profile Logging

A-15

• For information about SSL support in WebLogic Server, see SSL: An Introductionin Understanding Security for Oracle WebLogic Server.

• For information about JSEE, see Java Secure Socket Extension (JSEE)Reference Guide at http://download.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html.

New Web Services FeaturesOracle WebLogic Server 10.3.3 added several new Web services features, suchas support for Web services atomic transactions, enhanced support for clusteredenvironments, the ability to attach Oracle WSM policies to WebLogic Web servicesusing Fusion Middleware Control, and more.

The following new features have been added in WebLogic Server as of release 10.3.3:

• Support for Web services atomic transactions: WebLogic Web services enableinteroperability with other external transaction processing systems, such asWebSphere, JBoss, Microsoft .NET.

• Enhanced support for Web services in a clustered environment

• Enhanced monitoring of Web services and clients

• Attachment of Oracle WSM policies to WebLogic Web services using FusionMiddleware Control

• EclipseLink DBWS support for declarative Web service solution for accessingrelational databases

• Method-Level policy attachment behavior change: Before WebLogic Server 10.3.3,if a policy was attached, through the WebLogic Server Administration Console, toa method of one Web service, the policy was also attached to all methods of thesame name for all Web services in that module. As of WebLogic Server 10.3.3, thepolicy is attached only to the method of the appropriate Web service.

• policy: prefix now removed from OWSM policy names

• Web services WSDL tab now removed: Before WebLogic Server 10.3.3, you couldview the WSDL for the current Web service by selecting the Configuration >WSDL tab. The WSDL tab has been removed as of WebLogic Server 10.3.3.

• New development tools: Oracle JDeveloper and Oracle Enterprise Pack forEclipse (OEPE)

• Integration with Oracle Enterprise Manager Fusion Middleware Control

• Support for Oracle WebLogic Services Manager (WSM) security policies

• Support for WS-SecureConversation 1.3 on JAX-WS and MTOM with WS-Securityon JAX-WS

See What's New in Oracle WebLogic Server.

Introduction of JSSEAs of WebLogic Server 10.3.3, Java Secure Socket Extension (JSSE) was introducedas an SSL implementation. JSSE is the Java standard framework for SSL andTLS and includes both blocking-I/O and non-blocking-I/O APIs, and a referenceimplementation including several commonly-trusted CAs.

Appendix ANew Web Services Features

A-16

Performance Enhancements for Security Policy DeploymentAs of release 10.3.3, WebLogic Server includes a deployment performanceenhancement for Deployable Authorization providers and Role Mapping providers thatare thread safe. WebLogic Server by default supports thread-safe parallel modificationto security policy and roles during application and module deployment. For this reason,deployable Authorization and Role Mapping providers configured in the security realmshould support parallel calls. The WebLogic deployable XACML Authorization Providerand the WebLogic Server XACML Role Mapping Provider meet this requirement.However, if your custom deployable Authorization or Role Mapping providers donot support parallel calls, you must disable the parallel security policy and rolemodification and instead enforce a synchronization mechanism that results in eachapplication and module being placed in a queue and deployed sequentially. Youcan turn on this synchronization enforcement mechanism from the WebLogic ServerAdministration Console or by using the DeployableProviderSynchronizationEnabledand DeployableProviderSynchronizationTimeout attributes of the RealmMBean.

See Enabling Synchronization in Security Policy and Role Modification at Deploymentin Administering Security for Oracle WebLogic Server .

ActiveCacheAs of WebLogic Server 10.3.3, applications deployed on WebLogic Server can easilyuse Coherence data caches, and seamlessly incorporate Coherence*Web for sessionmanagement and TopLink Grid as an object-to-relational persistence framework.Collectively, these features are called ActiveCache. See About ActiveCache inDeploying Applications with Oracle WebLogic Server ActiveCache.

Class CachingAs of WebLogic Server 10.3.3, you can enable class caching in WebLogic Server. Theadvantages of using class caching are:

• Server startup time is reduced.

• The package level index reduces search time for all classes and resources.

Class caching is supported in development mode when starting the server using astartWebLogic script. Class caching is disabled by default and is not supported inproduction mode. The decrease in startup time varies among different JRE vendors.See Class Caching With the Policy Classloader in Developing Applications for OracleWebLogic Server.

Deprecated JDBC DriversThe WebLogic Type 4 JDBC driver for Oracle and Sybase JConnect 5.5 and 6.0drivers are deprecated.

• WebLogic Type 4 JDBC driver for Oracle

This driver was deprecated in WebLogic Server 10.3 and is now removed. Insteadof using this deprecated driver, use the Oracle Thin Driver that is provided withWebLogic Server. For details about the Oracle Thin Driver, see JDBC Drivers

Appendix APerformance Enhancements for Security Policy Deployment

A-17

Installed with WebLogic Server in Administering JDBC Data Sources for OracleWebLogic Server.

• Sybase JConnect 5.5 and 6.0 drivers

These drivers are removed from WebLogic Server as of release 10.3.3 due toan Oracle security policy regarding default installation of code samples. You candownload the driver from Sybase or you can use the Oracle-branded JDBC driverfor Sybase that is packaged with WebLogic Server.

Changes to weblogic.jms.extension APIAs of WebLogic Server 10.3.3, the internal methods of theweblogic.jms.extensions.WLMessage interface are removed from Java APIReference for Oracle WebLogic Server. These methods include the following:

public void setSAFSequenceName(String safSequenceName);public String getSAFSequenceName();public void setSAFSeqNumber(long seqNumber);public long getSAFSeqNumber();

Your applications should not use these internal methods. Internal methods maychange or be removed in a future release without notice.

Persistent Store UpdatesAs of WebLogic Server 10.3.3, WebLogic file store behavior and tuning have changedfor default file stores and custom file stores. For information about the SynchronousWrite Policy, which determines the behavior of the write operation of the file store, seeGuidelines for Configuring a Synchronous Write Policy in Administering the WebLogicPersistent Store.

Oracle Internet Directory and Oracle Virtual DirectoryAuthentication Providers

As of WebLogic Server 10.3.2, two new LDAP authentication providers, theOracle Internet Directory Authentication Provider and the Oracle Virtual DirectoryAuthentication Provider, are added to WebLogic Server. These authenticationproviders can store users and groups in and read users and groups from the OracleInternet Directory and Oracle Virtual Directory LDAP servers, respectively.

For information about configuring and using these new security providers, seeConfiguring LDAP Authentication Providers in Administering Security for OracleWebLogic Server.

CapacityIncrement AttributeAs of WebLogic Server 10.3.1, the CapacityIncrement attribute of theJDBCConnectionPoolMBean is no longer configurable and is set to a value of 1.

Appendix AChanges to weblogic.jms.extension API

A-18

Middleware Home DirectoryAs of WebLogic Server 10.3.1, Middleware Home replaces the notion of the BEAHome directory. The default path of this directory is <drive:>Oracle/Middleware.This change has the following impact on WebLogic Server:

• A new environment variable is introduced in several WebLogic scripts in 10.3.1to represent the Middleware Home directory: MW_HOME. The directory to whichthis variable is set generally is the same as BEA_HOME, which is also still used inWebLogic Server scripts.

• By default, the WebLogic Server installation program selects <drive:>Oracle/Middleware as the root product installation directory. However, if a directorycontaining an existing WebLogic Server installation is detected, that directory isselected instead by default.

• The WebLogic Server 10.3.1 documentation now uses the term MiddlewareHome, instead of BEA Home. However, this revision is functionally only a changein terminology. This revision does not imply that any WebLogic software, customdomains, or applications must be moved, or that any existing environmentvariables that represent those locations must be changed.

This change does not affect any existing WebLogic Server installations, customdomains, applications, or scripts on your computer. You can continue to use theBEA_HOME environment variable as before.

Resource Registration NameAs of WebLogic Server 10.3.1, the behavior of the resource registration name for XAdata source configurations has changed. In previous releases, the Java TransactionAPI (JTA) registration name was simply the name of the data source. StartingWebLogic Server 10.3.1, the registration name is a combination of data source nameand domain.

See Registering an XAResource to Participate in Transactions in Developing JTAApplications for Oracle WebLogic Server.

Servlet Path MappingAs of version 2.3 of the Java Servlet Specification, two additional characters, / and *,can be used to define mappings.

• A servlet path string that contains only the / (slash) character indicates the defaultservlet of the application. The servlet path resolves to the request URI minus thecontext path. In this case, the path resolves to null.

• A string that begins with an * (asterisk) specifies an extension mapping.

These changes introduce a change in behavior with the following HttpServletRequestmethods:

• getPathInfo

• getServletPath

Appendix AMiddleware Home Directory

A-19

To illustrate the change in behavior, consider the request /abc/def.html that resolvesto ServletA:

• If / maps to ServletA, then servletPath="abc/def.html" and pathInfo=null.

• If /* maps to ServletA, then servletPath="" and pathInfo="abc/def.html".

To ensure that the path information returned is non-null, replace all occurrences ofthe / (slash) servlet mapping string with /*.

If you define a servlet using both the @WebServlet annotation and the <servlet>element of the web.xml deployment descriptor file, you must make sure that the servletname you specify is the same in both locations. If the names do not match, then anexception is generated that prevents the application from starting. This requirementwas not enforced in versions of WebLogic Server 12c before 12.2.1.0.

You can download the Java Servlet Specification from the following location:

http://www.oracle.com/technetwork/java/javaee/servlet/index.html

Appendix AServlet Path Mapping

A-20