1 Introduction

You can upgrade WebLogic servers and domains from an earlier version of WebLogic Server to WebLogic Server 12c. You can also update an existing application to run on WebLogic Server 12.2.1.3.0.

While upgrading to version 12.2.1.3.0, you might want to change your application or you might have to change the application. However, this document focuses only on issues that you should consider when moving an application to WebLogic Server 12.2.1.3.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 Server 12.2.1.3.0

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

Note:

If you are upgrading from a release prior to WebLogic Server 10.3.1, see Upgrading 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 12.2.1.3.0, you do not need to run the Upgrade Assistant (UA) for schemas or configuration upgrades. You must only run the Reconfiguration Wizard. However, you must install the binaries in a new Oracle home and run the reconfiguration offline.

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

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

Note:

For information about upgrading your Java EE environment and your deployed applications from Oracle Application Server 10g and Oracle Containers for Java EE (OC4J) to WebLogic Server 12c release (12.2.1.3.0), see Fusion Middleware Upgrade Guide for Java EE.

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

WebLogic Server 12.2.1.3.0 includes the Fusion Middleware Reconfiguration Wizard to assist you with upgrading WebLogic Server and your application environments.

Most WebLogic Server applications can be run without modifications in the new WebLogic Server 12.2.1.3.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 Compatibility

Before you upgrade WebLogic Server, review the WebLogic Server and domain compatibility requirements for WebLogic Server 12.2.1.3.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 Minor Version. 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. Versions of WebLogic Server prior to 12.1.2 have slightly different compatibility allowances regarding specific WebLogic Server versions that are supported in a given domain.

Important Terminology

The documentation for upgrading WebLogic Server uses various terms when describing its features and functionality. It is important that you have a good understanding of these terms.

• Upgrade—In this document, the term upgrade refers to the process of upgrading WebLogic 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 a previous WebLogic Server version so that it is compatible with the WebLogic Server version to which you have upgraded. This can be done using either the Reconfiguration Wizard or WLST.

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

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

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

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

Upgrading From a WebLogic Version Prior to WebLogic Server 10.3.6

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

If you are currently using a WebLogic version prior to WebLogic Server 10.3.6, upgrading to version 12.2.1.3.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 at http://docs.oracle.com/middleware/11119/wls/WLUPG/intro.htm.

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

  Note:

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

  • Patch 13529623—10.3.6 Generic Upgrade Installer (does not include 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

• Upgrade WebLogic Server 10.3.6 to WebLogic Server 12.2.1.3.0 per the instructions in this guide.

  Note:

  As of WebLogic Server 12.1.2, Oracle no longer provides upgrade installers. You must install WebLogic Server 12.2.1.3.0 to a new directory location. You cannot install it over an existing installation.

Overview of the Upgrade Process

You can upgrade all WebLogic Server applications and domains simultaneously, upgrade them in a well-defined sequence, or upgrade some applications and domains while leaving other applications and domains on older WebLogic Server versions.

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

Figure 1-1 Example WebLogic Application Environment

Description of "Figure 1-1 Example WebLogic Application Environment"

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

Table 1-1 Upgrade Requirements for Components in Example WebLogic Application Environment

Component	Description	Upgrade Requirements
WebLogic domain	Includes the Administration Server (AS) and optionally one or more Managed Servers (for example, MS1, MS2, MS3, and MS4). The servers in a domain may span multiple machines. Furthermore, you can group Managed Servers into clusters to support load balancing and failover protection for critical applications. For more information about WebLogic domains, see Understanding Oracle WebLogic domains in Understanding Domain Configuration for Oracle WebLogic Server.	Upgrade the domain directory on each computer in the domain.
Applications	Any Java EE applications, including Web applications, EJBs, and so on. Typically, applications are deployed to one or more Managed Servers in a domain. Depending on the deployment strategy, applications may reside locally on a computer or be accessible using a shared directory. In addition, external client applications may access the application environment from outside a firewall.	Most WebLogic Server applications can be run without modifications in the new WebLogic Server 12.2.1.3.0 application environment. See Interoperability and Compatibility with Previous Releases.
External resources	Software components, such as databases for storing domain and application data, load balancers, and firewalls.	Verify that all external resources are compatible with WebLogic Server 12.2.1.3.0. See the Oracle Fusion Middleware Supported System Configurations page on the Oracle Technology Network.

Upgrading business applications that are deployed to WebLogic Server may involve upgrading multiple WebLogic Server applications, and in some cases domains, in a coordinated 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 Begin

Before you upgrade WebLogic Server, verify that your machine is set up to meet the requirements to upgrade and run WebLogic Server. You must also consider the scope of the environments that you are upgrading and which applications are upgraded in which 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 on upgrades that involve a single application running in a single domain.

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

• You typically upgrade an application either by upgrading an existing domain or by creating a new domain, from which you can run the application on the new WebLogic Server version. Sometimes, you prefer to create new domains using the Fusion Middleware Configuration Wizard or other configuration tools (such as WLST) to test the applications that you are upgrading.

  Note:

  If the domain was created using a WebLogic Server version prior to version 10.3.1, you must first upgrade to WebLogic Server 10.3.6. See Upgrading From a WebLogic Version Prior to WebLogic Server 10.3.6. After upgrading to WebLogic Server 10.3.6, run the WebLogic Server 10.3.6 Domain Upgrade Wizard to upgrade the domain. You can then use the Reconfiguration Wizard to upgrade the domain to WebLogic Server 12.2.1.3.0.

• When planning a WebLogic Server version upgrade, you should review the Fusion Middleware Supported Systems Configurations page on Oracle Technology Network (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 other vendors' products that you are using with WebLogic Server.

• On an ongoing basis, Oracle documents APIs and features that have been deprecated (that is, planned for removal in a future release). This is intended to inform you that you should avoid using these APIs and features to ensure upgradability. Oracle also documents the APIs and features that have actually been removed in the current release so that if you are upgrading from prior versions, you can determine if your applications will be affected by an upgrade.

  APIs and feature removals are cumulative. For example, if you are upgrading from WebLogic Server 10.0 to WebLogic Server 12.2.1.3.0, your applications may be affected by APIs or features that were removed in WebLogic Server 10.3, as well as by APIs or features that were removed in WebLogic Server 12.2.1.3.0. When upgrading, you should review all documentation of deprecated and removed features for all applicable WebLogic Server versions.

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

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

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

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

Interoperability and Compatibility with Previous Releases

Most existing WebLogic Server version 10.3.1 or later applications can be run without modification in the new WebLogic Server 12.2.1.3.0 application environment.

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

Patching an Existing WebLogic Server Installation

You can patch an existing WebLogic Server installation using either Zero Downtime Patching or manually rolling update of your servers.

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

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

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

About Zero Downtime Patching

As 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 a WebLogic Server installation.

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

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

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

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

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

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

About Rolling Updates

A rolling update preserves the state of active client sessions. During the rolling update process, client sessions are failed over from inactive servers to active servers to provide a seamless experience for your application users.

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

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

Note:

If your installation includes Oracle Enterprise Manager (EM), see Patching Software Deployments in Oracle Enterprise Manager Lifecycle Management Administrator's Guide.

Note the following limitations for rolling updates:

• You cannot use a rolling update to upgrade to a new minor version of WebLogic Server, for example from version 12.1.2 to 12.1.3. You can install only individual patches, patch bundles, or patch set updates (for example, 12.1.2.0.0 to 12.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 to a new minor version, you must install the new version in a new Oracle Home directory. 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 than the machines in the domain that are running only Managed Servers.

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

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

Performing a Rolling Update

To perform a rolling update using patches, bundle patches, or patch set updates for Oracle WebLogic Server, use the Oracle OPatch tool. The general process is as follows, 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 a server in the cluster.

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

   1. Complete any pending processes.

   2. 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 client sessions, you should wait a reasonable amount of time before shutting down the servers on the next machine in your upgrade sequence. The amount 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 client sessions.

Rolling Back a Patch, Bundle Patch, or Patch Set Update

Use the Oracle OPatch tool to roll back an applied patch, bundle patch, or patch set update.

• 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 Have Applied.

Obtaining a List of Applied Patches

Oracle WebLogic Server provides the ability to display the list of patches that have been applied to a WebLogic Server instance. The patch list can be obtained from either 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 for each 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 applied patches.

weblogic.log.DisplayPatchInfo System Property

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

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

• Running the weblogic.version utility. This utility can obtain the patch list regardless of whether the -Dweblogic.log.DisplayPatchInfo=true startup option is used, and does not require the WebLogic Server instance to be starting or running.

The following example shows running the weblogic.version utility. This example includes specifying the classpath of the weblogic.jar file corresponding to the specific server 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 1784838
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
 
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 also available from the ServerRuntimeMBean.PatchList attribute. The value of this attribute is independent of the weblogic.log.DisplayPatchInfo system property. You can access 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 an authenticated user whose identity can be mapped to the Admin role.

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

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

Example 1-1 Using WLST

The following example shows using WLST to connect to a server instance and obtain its 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".
 
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 Server instance 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:
 * 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();