1 Introduction

This document describes how to upgrade your servers and domains from an earlier WebLogic Server release to WebLogic Server 12c Release 1 (12.1.3) and, if necessary, how to update an existing application to run on WebLogic Server 12.1.3. Although you may decide to change your application when upgrading to WebLogic Server 12.1.3, and although in some cases you must change your application, this document focuses on issues that you should consider when moving an application to WebLogic Server 12.1.3 without making 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.1.3

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

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.1.

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.1.3, as well as how to upgrade Web Services.

WebLogic Server generally supports very 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 1 (12.1.3), see Oracle 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, refer to Planning an Upgrade of Oracle Fusion Middleware and the upgrade guides for each Fusion Middleware product in your installation.

WebLogic Server 12.1.3 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.1.3 application environment.

This chapter includes the following sections:

Version Compatibility

Prior to upgrade, you should review the WebLogic Server and domain compatibility requirements for WebLogic Server 12.1.3. For more information, see "Compatibility Within a Domain" in Understanding Oracle WebLogic Server.

Important Terminology

We recommend that, before proceeding, you familiarize yourself with the following terminology:

  • 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.1

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

  • you must first upgrade your installation to WebLogic Server 10.3.6. To do so, follow the instructions in Upgrade Guide for WebLogic Server 10.3.6. See http://docs.oracle.com/cd/E23943_01/web.1111/e13754/toc.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.1.3 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.1.3 to a new directory location. You cannot install it over an existing installation.

Overview of the Upgrade Process

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 follows
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.1.3 application environment. For more information, 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.1.3. For more information, 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 in order to:

  • maintain consistency in the WebLogic Server versions being used

  • use the same supported configurations environment across the entire installation

  • meet specific interoperability requirements.

For example, you may want to upgrade all 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.

Before You Begin

Before you begin the upgrade process, you should consider the scope of the environments that you are upgrading and which applications will be upgraded in which sequence. Covering all of the permutations of an upgrade is beyond the scope of this document. Therefore, you should 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 generally 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 will 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. In some cases, you may prefer to create new domains using the Fusion Middleware Configuration Wizard or other configuration tools (such as WLST) in order 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.1. 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.1.3.

  • 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.1.3, 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.1.3. 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.1.3. 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 10.3.1 or greater applications can be run without modification in the new WebLogic Server 12.1.3 application environment. You should review the compatibility information described in Appendix A, "WebLogic Server 12.1.3 Compatibility with Previous Releases," to determine whether any feature changes affect the applications in your environment. If your application uses APIs that have been deprecated or removed, then you may encounter warnings or exceptions at run time.

About Rolling Updates

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. 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.

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 for more information.

  • 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. For more information, 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. For more information, see the following topics in Patching with OPatch: