A WebLogic Server 14.1.1.0.0 Compatibility with Previous Releases

Learn about important compatibility information that you should consider before upgrading to Oracle WebLogic Server 14.1.1.0.0 from 10.3.x, 12.1.x, or 12.2.1.x release. Also learn about the feature changes in various Oracle WebLogic Server versions that may impact the applications you plan to run in the upgraded environment.

See also:

• WebLogic Server Compatibility in Understanding Oracle WebLogic Server. This section provides general information about WebLogic Server compatibility goals and 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 you as well as behavior changes that may impact your applications.

Compatibility considerations are provided in the following sections. The sections that apply to your situation depend on the WebLogic Server version from which you are upgrading to WebLogic Server 14.1.1.0.0. See compat.html#GUID-B63B1939-281E-4EDF-A40D-BCA824465F42__BABJDDJB for a list of sections to which you should refer based on your current WebLogic Server version.

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

If You Are Upgrading From This WebLogic Server 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 Resource Consumption 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 Starting WebLogic Server
12.1.3	All sections in the above row, plus: Random Number Generator Automatic Binding of the Default CommonJ Work Manager Has Been Removed Parallel Deployment
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.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 Been Removed Certicom SSL Implementation Has Been Removed Oracle Coherence Version Deprecated and Obsolete Web Application Features DataSource Profile Logging ONS Debugging Oracle Type 4 JDBC Drivers From DataDirect Default Message Mode Has Changed

Java EE 8 Support

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

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

Compatibility Changes When Migrating From JDK 8 to JDK 11

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, Javadoc API’s, xerces, Resource Consumption Management (RCM), and Sockets Direct Protocol (SDP) are removed in Java SE 11. In some cases, this change may require 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 the following 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 that reads and writes classes may need to be modified.
• There is a new Java version string scheme in Java SE 11.
• The following Java EE classes that were in the Java SE runtime have been removed 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, memory options, garbage collection options, endorsed standards, extension directory, and -source/target are fatal.
• All WebLogic Server jar files are intended to coexist with the JDK11 module system. However, the jar files continue to be on the classpath instead of the module path, which means that all jar files are part of the unnamed module.
• The application and platform class loaders are no longer instances of the java.net.URLClassLoader class. Code that depends on this to extend classloaders will no longer work.

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

Upgraded Version of Jython

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

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

Removed WebLogic Server Multitenant Functionality and Resource Consumption Management

WebLogic Server Multitenant domain partitions, resource groups, resource group templates, virtual targets, resource override configuration MBeans, and Resource Consumption Management have been removed from WebLogic Server as of version 14.1.1.0.0.

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

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

Removed WebLogic Full and IIOP-Based Clients

The following WebLogic clients have been removed from WebLogic Server as of version 14.1.1.0.0:

• The WebLogic Full client (wlfullclient.jar) and its associated WebLogic JarBuilder 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 WebLogic JARs in their class path).

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

Components and Features Removed in WebLogic Server 14.1.1.0.0

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

• EJBGen, an Enterprise JavaBeans 2.x code generator utility

  The use of EJB 3.0 no longer requires all of the code generation that EJBGen provided.

• 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 make necessary changes to the application code or configuration before upgrading to WebLogic Server 14.1.1.0.0. For more information, see Removed Functionality and Components in What's New in Oracle WebLogic Server.

About WebLogic Server Cluster Messaging

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

When you perform a rolling upgrade from 12.2.1.3.0 to 12.2.1.4.0 or a downgrade from 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 system property weblogic.upgradeExpirationDate with an expiration date, which enables the 12.2.1.4.0 server to allow communication on the cluster until that expiration date and time is reached. For example:

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

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

Note:

The system property -Dweblogic.upgradeExpirationDate must be used in the Server Start arguments for each of the Managed Servers, and not in the JAVA_OPTIONS environment variable in the startWebLogic.sh or startWebLogic.cmd scripts.

Upgraded Version of Apache Ant

Oracle WebLogic Server 12.2.1.3.0 includes Apache Ant 1.9.8, which may have an impact on the use of the clientgen Ant task. The clientgen Ant task generates, from an existing WSDL file, the client component files that client applications use to invoke both 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 data type, using the same attributes.

• In Apache Ant 1.9.8, the Ant FileSet data type is changed so that it may specify either 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 in WebLogic Web Services Reference for Oracle WebLogic Server.

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

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

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

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

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

Random Number Generator

Oracle WebLogic Server 14.1.1.0.0 uses a more secure random number generator algorithm than in previous releases. This can result in slow startup of Managed Servers, Configuration Wizard, Node Manager, and WebLogic Java utilities such as utils.ImportPrivateKey on low-entropy systems. Therefore, you should take steps to increase 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 to the 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 Manager Has Been Removed

The Work Manager API, commonj.work, provides a set of interfaces that allows an application to execute multiple work items concurrently within a container. Automatic binding of the default CommonJ Work Manager to java:comp/env/wm/default was removed in WebLogic Server 12.2.1 because it was not in compliance with the Java EE 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. For example:

  @Resource commonj.work.WorkManager myWorkManager;

Parallel Deployment

WebLogic Server 12.2.1 adds support for parallel deployment of applications and modules, which improves startup and post-running deployment time.

By default, in WebLogic domains that are created with, or upgraded to, WebLogic Server 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 deployed serially. The default deployment order is the natural order that is defined in the domain configuration (that is, as established in the config.xml file). However, in those earlier WebLogic Server releases, you can explicitly control deployment order by setting the DeploymentOrder attribute of the AppDeploymentMBean, using the WebLogic Server Administration Console or programmatically as explained in Changing the Deployment Order for Applications and Standalone Modules in Deploying Applications to Oracle WebLogic Server. The use of this feature with older releases is important if specific dependencies exist between applications.

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

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

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

However, disabling the preceding attributes prevents you from being able to take advantage of the significant performance benefits of parallel deployment. Instead of disabling parallel deployment altogether in the domain you are upgrading to WebLogic Server 14.1.1.0.0, Oracle recommends checking to see whether the deployment ordering of any applications or modules has been customized, and if so, whether it is necessary.

See:

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

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

Server Logging Bridge

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

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

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

• If weblogic.logging.ServerLoggingHandler is attached to a logger other than the root, Oracle strongly recommends that you either remove it from the logging.properties configuration, or set the useParentHandlers attribute to false (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 as log4j.additivity.com.foo.bar=false in the log4j.properties file.

Oracle Database Drivers

As of release 12.1.2, WebLogic Server installation includes the Oracle Database 12c drivers.

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 in the 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 also requires 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 FastPath

Oracle Enable JavaNet Fastpath enables the Oracle JDBC JavaNet Fastpath to reduce data copies and fragmentation. As of WebLogic Server 12.1.3, this attribute is no longer supported in the WebLogic Server Administration Console.

In previous versions of WebLogic Server, you could configure the Oracle Enable JavaNet FastPath attribute on the Configuration:Oracle tab in the WebLogic Server Administration Console. To go to the Configuration:Oracle tab, click Domain Structure, click Services, and then click Data Sources in the WebLogic Server Administration Console.

Maximum POST Size

A new session descriptor, max-save-post-size, has been added in WebLogic Server 12.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 during FORM 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 FORM authentication, you must increase max-save-post-size to an appropriate value. Otherwise, a MaxPostSizeExceededException occurs in the browser.

WLDF Schema Upgrade

If 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 your database.

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

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

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

jdbc-connection-timeout-secs Element Has Been Removed

The jdbc-connection-timeout-secs element in the weblogic.xml deployment descriptor has been removed in WebLogic Server 12.1.2. If your application configures the jdbc-connection-timeout-secs element, you must remove it from the weblogic.xml deployment descriptor to prevent deployment of the application from failing.

Commitment of Local Transactions

As of WebLogic Server 12.1.2, local transactions on non-XA connections that were not committed or rolled back by the application are now explicitly committed by default when the connection is returned to the pool. In addition, the following two parameters have been added to set whether or not local transactions on non-XA and XA connections are committed when the connection pool is closed:

• -Dweblogic.datasource.endLocalTxOnNonXAConWithCommit=false can be used to avoid one extra DBMS round-trip with non-XA connections, for applications that are trusted to always complete their transaction explicitly. If this parameter is set to false, local transactions on non-XA connections are implicitly committed or rolled back when a connection pool is closed, according to what the particular JDBC driver being used does when setAutoCommit(true) is called. Per the JDBC specification, that action is to commit the transaction, but there is varied compliance among drivers. By default, or if the property is set to true, these transactions are now committed.

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

JVM Settings

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

When upgrading a WebLogic Server 10.3.x domain to a WebLogic Server 14.1.1.0.0 or a greater domain and when running on Java SE 8 (but not Java SE 11 or later), you may 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 Server

In the following situation, you do not need to manually set the location of the Java endorsed directory (or directories) for WebLogic Server:

• You are using Oracle WebLogic Server 14.1.1.0.0 or greater domains when running on Java SE 8 (but not Java SE 11 or later) and start scripts that were generated by domain creation via the WebLogic Server 14.1.1.0.0 or greater Configuration Wizard, or your start scripts reference setDomainEnv.cmd/sh as generated by domain creation via the WebLogic Server 14.1.1.0.0 or greater Configuration Wizard.

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

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

• 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 Managed Server startup command.

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

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

Note:

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

You can also specify this value when calling startServer by passing the values as jvmArgs, 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") parameter in the ServerStartMBean's arguments attribute, either using WLST or the WebLogic Server Administration Console. If using the WebLogic Server Administration Console, enter this parameter in the Arguments field on the server's Configuration > Server Start 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 click Start for the server in the WebLogic Server Administration Console.

Setting permgen space

If 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 the maximum permgen space to at least 256M.

Note:

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

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

Description of the illustration permgen_setting1.gif

Note:

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

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 click on the Start 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 and specify 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 as jvmArgs, 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 Value

As of WebLogic Server 12.1.1, the default value for startScriptEnabled has been changed to true. In all previous releases, the default was false. If you do not want to use 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 WebLogic Server 12.1.1, EclipseLink is the default JPA provider, replacing Kodo. Applications that use Kodo as the persistence provider with WebLogic Server 12.1.2 must be updated. See Updating Applications to Overcome Conflicts in Developing Enterprise JavaBeans for Oracle WebLogic Server.

As of WebLogic Server 12.1.1, support for JPA 2.0 is built in. JPA 2.0 includes improvements and enhancements to domain modeling, object/relational mapping, EntityManager and Query interfaces, and the Java Persistence Query Language (JPQL), and more. See Setting the Default Provider for the Domain in Developing Enterprise JavaBeans for Oracle WebLogic Server.

WebLogic Server 8.1 Web Services Stack Has Been Removed

In WebLogic Server 12.1.1 release, the WebLogic Server 8.1 Web services stack has been removed. Therefore, WebLogic Server 8.1 Web services applications will no longer work.

Universal Description and Discover (UDDI) Registry Has Been 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, Oracle recommends that you migrate to the Oracle Service Registry (OSR). OSR UDDI 3.0 compliant.

Certicom SSL Implementation Has Been Removed

In WebLogic Server release 12.1.1, the Certicom SSL implementation has been removed.

This change may require you to update system properties and debug switches as described in Command Line Properties for Enabling SSL Debugging and System Property Differences Between the JSSE and Certicom SSL Implementations in Administering Security for Oracle WebLogic Server.

Oracle Coherence Version

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

Deprecated and Obsolete Web Application Features

See the list of Web application features that have been deprecated from, or are no longer supported in, Oracle WebLogic Server 12.1.1.

• Information about deprecated functionality in Oracle WebLogic Server 11g Release 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 Server 12.1.1 can be found on My Oracle Support at https://support.oracle.com/. Search for Deprecated Features.

DataSource Profile Logging

To provide better usability and performance, Oracle WebLogic Server 10.3.6 and later uses a data source profile log to store events. See Monitoring WebLogic JDBC Resources in Administering JDBC Data Sources for Oracle WebLogic Server.

ONS Debugging

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

Oracle Type 4 JDBC Drivers From DataDirect

As of Oracle WebLogic Server 10.3.6, Oracle Type 4 JDBC drivers from DataDirect are referred to as WebLogic-branded DataDirect drivers. Oracle has removed the documentation in Oracle® Fusion Middleware Type 4 JDBC Drivers for Oracle WebLogic Server and no longer provides detailed information about DataDirect drivers. Oracle continues to provide information about how WebLogic-branded drivers are configured and used in WebLogic Server environments at Using WebLogic-branded DataDirect Drivers in Developing JDBC Applications for Oracle WebLogic Server.

Oracle recommends reviewing DataDirect documentation for detailed information about driver behavior. See Progress DataDirect for JDBC User's Guide Release 5.1 and Progress DataDirect for JDBC Reference Release 5.1at http://www.datadirect.com/index.html.

Default Message Mode Has Changed

As of WebLogic Server 12.1.1, the default messaging mode has been changed from multicast to unicast. When creating a new cluster, Oracle recommends the use of unicast for messaging within a cluster. For backward compatibility with previous versions of WebLogic Server, you must use multicast for communications between clusters.