Oracle attempts to support binary and source-level compatibility between the current version of WebLogic Server and all versions as far back as 8.1 in the areas of persistent data, generated classes, and API compatibility. In some cases, it is impossible to avoid incompatibilities. Where incompatibilities arise, they are fully documented in the Upgrade Guide for Oracle WebLogic Server.
WebLogic Server 11g Release 1 (10.3.6) is Java EE 5 compatible. This compatibility allows a Java EE 5 compliant application to be developed on one operating system platform, and deployed for production on another, without requiring Java EE 5 application code changes. Oracle ensures this compatibility of Java EE 5 application portability within a WebLogic Server release level.
With one exception, upgrading to WebLogic Server 11g Release 1 (10.3.6) does not require you to recompile applications in order to create new generated classes.
The current version of the EJBGen utility recognizes only JDK 5.0 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 updated version of EJBGen.
All WebLogic Server instances within the same Administrative domain must be at the same major and minor version. You cannot mix server versions within a domain.
In general, the best practice is for all server instances within a domain to be at the same Patch Set level during steady-state operation. However, there may be cases where server instances are required to run at different Patch Set levels. The primary examples include:
When applying a Patch Set in rolling fashion across server instances in the domain. In such cases, the Patch Set should be applied to the Administration Server first, so that the Administration Server is at the same Patch Set level or higher than its Managed Servers.
When there are specific requirements to run Managed Servers within a domain at different Patch Set levels in steady-state operation. In such cases, the Administration Server should be at the highest Patch Set level, so that the Administration Server is at the same Patch Set level or higher than all of the Managed Servers. Such domains can only use configuration features that are supported on all Managed Servers in the domain. This configuration restriction may be difficult to enforce, which is why the general best practice is to use the same Patch Set level across servers within a domain during steady-state operation.
All server instances within a cluster must be at the same Patch Set level, except when performing a rolling upgrade of Patch Sets across Managed Servers in a cluster.
In general, the best practice is for all server instances within a domain to be at the same Patch Set Update (PSU) and Interim/One-off Patch level during steady-state operation. However, there may be cases where server instances are required to run at different PSUs or Interim/One-off Patch levels within a domain. The primary examples include:
When applying PSUs or Interim/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/One-off Patch level or higher than its Managed Servers.
When there are specific requirements to run Managed Servers within a domain at different PSU or Interim/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/One-off Patches, it will not be possible to apply a consistent set of Interim/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/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 Supported System Configurations page at http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html. 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.
When moving from WebLogic Server 8.1 to 10.3.6, there are changes required to configuration files. Upgrade tooling in WebLogic Server versions 9.0 and later automatically convert the configuration files for you.
WebLogic Server 8.1, 9.x, 10.0, and 10.3.x applications deployed on WebLogic Server 11g Release 1 (10.3.6) will function without modification. Exceptions to this rule include cases where API behavior was changed in order to conform to a specification or to fix incorrect behavior. In certain circumstances, a correction may cause your application to behave differently.
Interoperability between WebLogic Server 11g Release 1 (10.3.6) and WebLogic Server 8.1, 9.x, 10.0, and 10.3.x is supported in the following scenarios:
A WebLogic Server 8.1, 9.x, 10.0, and 10.3.x client can invoke RMI-based applications hosted on a WebLogic Server 10.3.6 server using IIOP, T3, T3S, HTTP, and HTTPS. JMS applications can be invoked using T3, T3S, HTTP, and HTTPS.
A WebLogic Server 10.3.6 client can invoke RMI-based applications hosted on a WebLogic Server 8.1, 9.x, 10.0, and 10.3.x server using IIOP, T3, T3S, HTTP, and HTTPS. JMS applications can be invoked using T3, T3S, HTTP, and HTTPS.
A WebLogic Server 10.3.6 Web server plug-in can proxy to the latest patch set release of a 8.1, 9.x, 10.0, and 10.3.x server.
See "JMX 1.2 Implementation" in WebLogic Server 11g Release 1 (10.3.6) Compatibility with Previous Releases.