This chapter includes the following topics:
WebLogic Server 12c (220.127.116.11.0) is Java EE 7 compatible. This compatibility allows a Java EE 7 compliant application to be developed on one operating system platform, and deployed for production on another, without requiring Java EE 7 application code changes.
Oracle ensures this compatibility of Java EE 7 application portability within a WebLogic Server release level.
With one exception, upgrading to WebLogic Server 12c (18.104.22.168.0) does not require you to recompile applications in order to create new generated classes.
The version of the EJBGen utility that is included in WebLogic Server 12c recognizes only JDK 5.0 or later metadata annotation-style EJBGen tags and not the old Javadoc-style tags. This means that source files that use the Javadoc-style tags must be upgraded to use the equivalent annotation, and then recompiled using the current version of EJBGen.
Within the scope of a WebLogic domain, Oracle WebLogic Server supports a wide range of compatibility with respect to the specific versions of WebLogic Server instances that can run in that domain, as well as the mix of hardware, operating system, and JVM platforms on which those server instances can run.
However, depending upon the specific configurations present in the domain, such as WebLogic clusters, Oracle has specific recommendations for how you can achieve optimal performance. The following topics provide key information regarding compatibility within WebLogic domains:
Within a WebLogic domain, the Administration Server, Managed Server instances, and the domain itself each have a WebLogic Server version number. The version number contains five decimal places; for example, WebLogic Server 22.214.171.124.0. The meaning of each decimal place is described below:
The first two decimal places together describe the Major Version number, for example "12.2" in 126.96.36.199.0. The WebLogic Server 12.2 Major Version release is also branded as the WebLogic Server 12cR2 Major Version release.
The first three decimal places together describe the Minor Version number, for example "12.2.1" in 188.8.131.52.0. WebLogic Server 12.2.1 (or 184.108.40.206.0) was the first Minor Version release of the WebLogic Server 12.2 Major Version release. WebLogic Server 12.1.3 (or 220.127.116.11.0) is the third Minor Version release of the WebLogic Server 12.1 Major Version release.
Patch Set releases for WebLogic Server 18.104.22.168.0 increment the fourth decimal place. For example, 22.214.171.124.0 is the first patch set release.
Patch Set Update releases are named uniquely by incrementing the fifth decimal place with the date of the Patch Set Update release in YYMMDD format; for example, 126.96.36.199.160719. This convention is used for Patch Set Update naming purposes; for example, naming downloads available on My Oracle Support. However, the application of a Patch Set Update does not change the version number of an existing WebLogic Server installation as referenced in the Oracle inventory directory (
oraInventory) used by WebLogic Server 12.2.1 installers.
You can obtain the version number and Patch Set level of a WebLogic Server instance or domain several different ways. For example:
For an Administration Server or Managed Server instance, you can view the version message sent to
stdout when the server is started. For example:
<Version: WebLogic Server 188.8.131.52.0 Thu Aug 13 16:15:36 PDT 2015 1698759 >
For a domain, you can view the value of the
<domain-version> element in the domain configuration file,
config.xml. For example:
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, the Administration Server, Managed Servers, and the WebLogic domain must all be at version 12.2.1. Note the following guidelines for maintaining consistency in Patch Set Update and Interim or One-off Patch levels within a domain.
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. See Upgrading Oracle WebLogic Server.
In general, the best practice is for all server instances within a domain to be at the same Patch Set Update (PSU) and Interim or One-off Patch level during steady-state operation. However, there may be cases where server instances are required to run at different PSUs and Interim or One-off Patch levels within a domain. The primary examples include:
When applying PSUs, Interim or One-off Patches in rolling fashion across server instances in the domain. In such cases, the maintenance should be applied to the Administration Server first, so that the Administration Server is at the same PSU and Interim or One-off Patch level (or higher) than its Managed Servers. See About Rolling Upgrade in Upgrading Oracle WebLogic Server.
When there are specific requirements to run Managed Servers within a domain at different PSU and Interim or One-off Patch levels in steady-state operation. In such cases, the Administration Server should be at the highest PSU level, so that the Administration Server is at the same PSU level or higher than all of the Managed Servers. If Managed Servers within a domain are running with different Interim or One-off Patches, it will not be possible to apply a consistent set of Interim or One-off Patches to the Administration Server. Because this maintenance complexity may be difficult to manage, the general best practice is to use the same PSU and Interim or One-off Patch level across all servers in the domain.
Server instances within a cluster or domain can run on any hardware and operating systems as long as the hardware and operating systems are listed on the Oracle Fusion Middleware Supported System Configurations page on Oracle Technology Network. However, note that running clustered Managed Server instances on different hardware and operating systems may impact load balancing and performance. In general, the best practice is to run all Managed Servers within a cluster on the same hardware and operating system.
If the WebLogic domain is part of an Oracle Enterprise Manager Cloud Control installation, additional requirements exist regarding the combinations of hardware, operating system, and JVMs, that may be configured in the domain. See Oracle Enterprise Manager Cloud Control Administrator's Guide.
For more information about WebLogic domains, see Understanding Domain Configuration for Oracle WebLogic Server (note especially the section Domain Restrictions, which provides additional details about domain compatibility).
WebLogic Server instances within a domain can run on any hardware, operating system, and JVM platform as long as the hardware, operating systems, and JVMs are supported for the current version of WebLogic Server. For details, see the Oracle Fusion Middleware Supported System Configurations page on the Oracle Technology Network.
Although this platform compatibility support extends to Managed Server instances within a cluster, Oracle strongly recommends that clusters be homogeneous with respect to the underlying hardware, operating system, and JVM. Managed Server instances running in the same cluster are assumed to be equivalent, so running clustered server instances on mixed platforms may have a negative impact on load balancing and performance. If you must operate a cluster on a mixed platform, Oracle strongly recommends that you understand the load balancing and performance implications.
As a best practice, Oracle recommends that the version of Node Manager used in a WebLogic domain should match the version of the Administration Server.
If you are running a version of WebLogic Server prior to 12.1.2, see Upgrading Oracle WebLogic Server for additional Node Manager compatibility information that may be applicable to your environment. For more information about Node Manager compatibility, see Administering Node Manager for Oracle WebLogic Server.
For a list of previously deprecated APIs that are removed in Oracle WebLogic Server 184.108.40.206.0, see Removed Functionality and Components in What’s New in Oracle WebLogic Server 220.127.116.11.0.
Interoperability between WebLogic Server 12c (18.104.22.168.0) and WebLogic Server 10.0, 10.3.x, 12.1.1, 12.1.2, and 12.1.3 is supported in several scenarios with regards to WebLogic clients, transport protocols, and WebLogic proxy plug-ins. However, a key interoperability restriction exists regarding WebLogic domains that are configured to use Compatibility security.
The supported interoperability scenarios are the following:
A WebLogic Server 10.0, 10.3.x, 12.1.1, 12.1.2, and 12.1.3 client can invoke RMI-based applications hosted on a WebLogic Server 12c 22.214.171.124.0) server using IIOP, T3, T3S, HTTP, and HTTPS. JMS applications can be invoked using T3, T3S, HTTP, and HTTPS.
A WebLogic Server 12c (126.96.36.199.0) client can invoke RMI-based applications hosted on a WebLogic Server 10.0, 10.3.x, 12.1.1, 12.1.2, and 12.1.3 server using IIOP, T3, T3S, HTTP, and HTTPS. JMS applications can be invoked using T3, T3S, HTTP, and HTTPS.
A WebLogic proxy plug-in can proxy to the latest patch set release of a 10.0, 10.3.x, 12.1.1, 12.1.2, and 12.1.3 server.
One important restriction is with regards to interoperability between WebLogic Server 12c (188.8.131.52.0) and an older release of WebLogic Server that uses Compatibility security. As of WebLogic Server version 12.2.1, support for Compatibility security is removed in both the server and client. To enable interoperability with a version of WebLogic Server that uses Compatibility security, you can choose one of the following options:
Configure the network channel used for communicating with the older WebLogic Server domain to use the IIOP protocol instead of T3. See Configuring Network Resources in Administering Server Environments for Oracle WebLogic Server.
Use a WebLogic Server version 12.1.3 or prior client. See Overview of Standalone Clients in Developing Standalone Clients for Oracle WebLogic Server.
Upgrade the domain of the older WebLogic Server release so that it no longer uses Compatibility security.