A WebLogic Server 12.2.1.1.0 Compatibility with Previous Releases

This appendix describes important compatibility information that you should consider before upgrading to WebLogic Server 12.2.1.1.0 from a WebLogic Server 10.3.x or 12.1.x release. In particular, this appendix covers feature changes in various 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 12.2.1.1.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 12.2.1.1.0. Refer to Table A-1 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.1.3	Random Number Generator Partitions, Applications, and Container Context Root Assumptions 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 Commitment of Local Transactions
10.3.5 and 10.3.6	All sections in the above rows, plus: JVM Settings Node Manager startScriptEnabled Default 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 Coherence Version Deprecated and Obsolete Web Application Features Evaluation Database Changed From PointBase to Derby Data Source Profile Logging ONS Debugging Oracle Type 4 JDBC drivers from DataDirect Default Message Mode Has Changed
10.3.3 and 10.3.4	All sections in the above rows, plus: Modifications to SSLMBean
10.3.2	All sections in the above rows, plus: New Web Services Features Introduction of JSSE Performance Enhancements for Security Policy Deployment ActiveCache Class Caching Deprecated JDBC Drivers Changes to weblogic.jms.extension API Persistent Store Updates
10.3.1	All sections in the above rows, plus: Oracle Internet Directory and Oracle Virtual Directory Authentication Providers
10.3.0	All sections in the above rows, plus: capacityIncrement Attribute Middleware Home Directory Resource Registration Name Servlet Path Mapping

Random Number Generator

WebLogic 12.2.1.1.0 is using a more secure random number generator algorithm than was used 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, and you should therefore take steps to increase system entropy.

On Linux 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, which will add bits to the entropy pool every 60 seconds until the pool reaches the size of 2048.

Use the following command to manually generate entropy:

rngd -r /dev/urandom -o /dev/random -b

Use the following command to check current entropy:

cat /proc/sys/kernel/random/entropy_avail

Partitions, Applications, and Container Context Root Assumptions

Java EE applications that make assumptions concerning the context root of their Web container may need to be modified if they are deployed to a virtual target that has a uriPrefix set. In this case, the context path of the application includes the uriPrefix of the virtual target.

Some examples of this are:

• The application parses the incoming URL to construct another URL. If this parsing assumes that the URL root ends at host:port, the application needs to be updated because the URL root will be host:port/prefix with URI-based routing.

  The MedRec sample application is one example of this. MedRec used to parse the incoming URL to construct another URL, and assumed that the root URL consisted of only host:port. To address this, the following changes were made to the MedRec application:

  • The original code in the JaxWsProperties.java file for the physician application was:

    public final static String WSURL = "http://"
                 + ServerPropertiesUtils.getServerAddress("physician", "localhost")
                 + ":"
                 + ServerPropertiesUtils.getServerPort("7001")
                 + "/medrec-jaxws-services/";
    

    This was changed to the following code. ServerPropertiesUtils.getRegion() accounts for the possibility of a partition URI prefix in the URL:

    public final static String WSURL = "http://" 
             + ServerPropertiesUtils.getRegion() + "medrec-jaxws-services/";
    

  • The original code in the GettingHostFilter.java file for the physician Web application was:

    ServerPropertiesUtils.setAddress(request.getServerName());
    ServerPropertiesUtils.setPort(String.valueOf(request.getServerPort()));
    chain.doFilter(request, response);
    

    This was changed to the following code to preserve host:port or, if using MT URI-based routing, host:port/partition for the Web service client:

    if (ServerPropertiesUtils.getRegion() == null ||
     ServerPropertiesUtils.getRegion().equals("")) {
       StringBuilder builder = new StringBuilder();
       builder.append(request.getServerName());
       builder.append(":");
       builder.append(String.valueOf(request.getServerPort()));
       builder.append(partition);
       ServerPropertiesUtils.setRegion(builder.toString());
    

• The application links to "/" in HTML/JSP code. In a non-MT environment, the application may make an assumption about the context root to which it is deployed. For example, consider an application that is deployed with the context root /fruits and that includes a page that refers to:

  <a href="/fruits/index.html">Back to Fruits List</a>
  

  This type of absolute reference does not work if the application is deployed to a partition with a virtual target that uses a URI prefix. The preceding link will try to go to host:port/fruits/index.html instead of host:port/partition1/fruits/index.html. The safest approach is to use relative URLs in links, such as:

  <a href="index.html">Back to Fruits List</a>
  

Automatic Binding of the Default CommonJ Work Manager Has Been Removed

Automatic binding of the default CommonJ Work Manager to java:comp/env/wm/default has been removed in WebLogic Server 12.2.1 because it is 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 either:

• 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. Parallel deployment of applications enables applications with the same deployment order to be deployed in parallel to each other. By contrast, parallel deployment of modules enables modules within a single application archive to be deployed in parallel to each other.

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, 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 12.2.1.1.0, or upgrade an existing domain to 12.2.1.1.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 12.2.1.1.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. For more information, 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

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

The above 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

The WLS installation now 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

The Oracle Enable JavaNet FastPath attribute on the Domain Structure > Services > Data Sources > Configuration:Oracle tab of the WebLogic Server Administration Console is no longer supported.

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 will be saved or buffered by the application container during FORM authentication. The default value 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 will occur in the browser.

WLDF Schema Upgrade

If you are using a JDBC-based store for 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. For more information, see "Configuring a JDBC-Based Store" in Configuring and Using the Diagnostics Framework for Oracle WebLogic Server.

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

jdbc-connection-timeout-secs Element

As of WebLogic Server 12.1.2, 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 will be 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

When upgrading a WebLogic Server 10.3.x domain to a WebLogic Server 12.1.2 or greater domain, you may have to:

• manually set the location of the Java endorsed directory (JRE_HOME/lib/endorsed) or directories.

• manually increase the permgen space and maximum permgen space for the Oracle HotSpot JDK.

Setting the Location of the Java Endorsed Directory

In the following situations, you do not need to manually set the location of the Java endorsed directory or directories:

• you are using JDK7.

• you are using one of the JDKs that is installed with WebLogic Server 12.1.1.

• you are using WLS 12c domains and start scripts that were generated by domain creation via the WebLogic Server 12c Configuration Wizard, or your start scripts reference commEnv.cmd/sh as installed by the WebLogic Server installer, or both.

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 in the command you use to start your Managed Servers:

• you are using Node Manager to start your Managed Servers, but you are not using a start script, that is startScriptEnabled=false. Note that as of WebLogic Server 12.1.1, the default value for startScriptEnabled is true.

• 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=WL_HOME/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 WL_HOME with the full 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=/WL_HOME/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=/WL_HOME/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 on the Start button 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 GUID-F8005917-21C7-42D5-8D21-B8D27B71B909-default.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:

(UNIX) startManagedWebLogic.sh server_name -XX:PermSize=128m -XX:MaxPermSize=256m

(Windows) startManagedWebLogic.cmd server_name -XX:PermSize=128m -XX:MaxPermSize=256m

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

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 continue to use Kodo as the persistence provider with WebLogic Server 12.1.2 will need to be updated. For more information, 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. For more information, see "Using JPA 2.0 with TopLink in WebLogic Server" in Developing Enterprise JavaBeans for Oracle WebLogic Server.

WebLogic Server 8.1 Web Services Stack Has Been Removed

The WebLogic Server 8.1 Web services stack has been removed in the WebLogic Server 12.1.1 release. Therefore, WebLogic Server 8.1 Web services applications will no longer work. Oracle recommends that you upgrade such applications to the WebLogic JAX-RPC or JAX-WS stacks, per the instructions in Upgrading an 8.1 WebLogic Web Service to 12.1.x.

Universal Description and Discover (UDDI) Registry Has Been Removed

The Universal Description and Discovery (UDDI) registry has been removed as of WebLogic Server 12.1.1. 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), which is UDDI 3.0 compliant.

Certicom SSL Implementation

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

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

For a list of Web application features that are deprecated or are not supported as of WebLogic Server 12.1.1, refer to the following:

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

Evaluation Database Changed From PointBase to Derby

As of WebLogic Server 10.3.3, the evaluation database available from the WebLogic Server installation program has been changed from PointBase to Apache Derby. If you select the Evaluation Database option on the Choose Products and Components screen, the Derby database is installed in the WL_HOME\common\derby directory. If you select a Typical installation, Derby is installed by default.

If you have a domain based on PointBase and you want to continue using PointBase after upgrading the domain to WebLogic Server 10.3.3 or later, you must obtain a PointBase license from http://www.pointbase.com. Note that the full WLS installer does not preserve the PointBase installation directory. As an alternative to using PointBase, you can migrate the domain database to Derby.

For more information, see Upgrading a Domain that Uses an Evaluation Database.

Data Source Profile Logging

To provide better usability and performance, WebLogic Server 10.3.6 and higher 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

For WebLogic Server release 10.3.6 and higher, the package names for UCP and ONS are no longer repackaged. For information on how to set UPC 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 WebLogic Server 10.3.6, Oracle Type 4 JDBC drivers from DataDirect are referred to as WebLogic-branded DataDirect drivers. Oracle has retired the documentation in Oracle® Fusion Middleware Type 4 JDBC Drivers for Oracle WebLogic Server and no longer provides detailed information on DataDirect drivers. Oracle continues to provide information on 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 on driver behavior. See "Progress DataDirect for JDBC User's Guide Release 5.1" and "Progress DataDirect for JDBC Reference Release 5.1" at 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.

Modifications to SSLMBean

The SSLMBean has been modified as of WebLogic Server 10.3.5 to support additional SSL configuration capabilities, including the ability to enable or disable the JSSE adapter.

For more information, see the following documents:

• For a list of the differences in the way the JSSE SSL implementation handles the WebLogic system properties, see System Property Differences Between the JSSE and Certicom SSL Implementations in Administering Security for Oracle WebLogic Server.

• For more information about SSL support in WebLogic Server, see SSL: An Introduction in Understanding Security for Oracle WebLogic Server.

• For more information on JSEE, see "Java Secure Socket Extension (JSEE) Reference Guide" at http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html.

New Web Services Features

The following new features have been added in WebLogic Server as of release 10.3.3:

• Support for Web services atomic transactions—WebLogic Web services enable interoperability with other external transaction processing systems, such as WebSphere, JBoss, Microsoft .NET.

• Enhanced support for Web services in a clustered environment

• Enhanced monitoring of Web services and clients

• Attachment of Oracle WSM policies to WebLogic Web services using Fusion Middleware Control

• EclipseLink DBWS support for declarative Web service solution for accessing relational databases

• Method-Level policy attachment behavior change—Before WebLogic Server 10.3.3, if a policy was attached, through the WebLogic Server Administration Console, to a method of one Web service, the policy was also attached to all methods of the same name for all Web services in that module. As of WebLogic Server 10.3.3, the policy is attached only to the method of the appropriate Web service.

• policy: prefix now removed from OWSM policy names

• Web services WSDL tab now removed—Before WebLogic Server 10.3.3, you could view the WSDL for the current Web service by selecting the Configuration > WSDL tab. The WSDL tab has been removed as of WebLogic Server 10.3.3.

• New development tools—Oracle JDeveloper and Oracle Enterprise Pack for Eclipse (OEPE)

• Integration with Oracle Enterprise Manager Fusion Middleware Control

• Support for Oracle WebLogic Services Manager (WSM) security policies

• Support for WS-SecureConversation 1.3 on JAX-WS and MTOM with WS-Security on JAX-WS

For more information, see "Web Services" in What's New in Oracle WebLogic Server.

Introduction of JSSE

As of WebLogic Server 10.3.3, Java Secure Socket Extension (JSSE) was introduced as an SSL implementation. JSSE is the Java standard framework for SSL and TLS and includes both blocking-I/O and non-blocking-I/O APIs, and a reference implementation including several commonly-trusted CAs.

Performance Enhancements for Security Policy Deployment

As of release 10.3.3, WebLogic Server includes a deployment performance enhancement for Deployable Authorization providers and Role Mapping providers that are thread safe. WebLogic Server by default supports thread-safe parallel modification to security policy and roles during application and module deployment. For this reason, deployable Authorization and Role Mapping providers configured in the security realm should support parallel calls. The WebLogic deployable XACML Authorization and Role Mapping providers meet this requirement.

However, if your custom deployable Authorization or Role Mapping providers do not support parallel calls, you must disable the parallel security policy and role modification and instead enforce a synchronization mechanism that results in each application and module being placed in a queue and deployed sequentially. You can turn on this synchronization enforcement mechanism from the WebLogic Server Administration Console or by using the DeployableProviderSynchronizationEnabled and DeployableProviderSynchronizationTimeout attributes of the RealmMBean.

See Enabling Synchronization in Security Policy and Role Modification at Deployment in Administering Security for Oracle WebLogic Server for additional information.

ActiveCache

As of WebLogic Server 10.3.3, applications deployed on WebLogic Server can easily use Coherence data caches, and seamlessly incorporate Coherence*Web for session management and TopLink Grid as an object-to-relational persistence framework. Collectively, these features are called ActiveCache.

ActiveCache provides replicated and distributed data management and caching services that you can use to reliably make an application's objects and data available to all servers in a Coherence cluster.

For more information, see .

Class Caching

As of release 10.3.3, WebLogic Server allows you to enable class caching. The advantages of using class caching are:

• Reduces server startup time.

• The package level index reduces search time for all classes and resources.

Class caching is supported in development mode when starting the server using a startWebLogic script. Class caching is disabled by default and is not supported in production mode. The decrease in startup time varies among different JRE vendors. For more information, see "Configuring Class Caching" in Developing Applications for Oracle WebLogic Server.

Deprecated JDBC Drivers

The following JDBC drivers are deprecated:

• WebLogic Type 4 JDBC driver for Oracle

  This driver was deprecated in WebLogic Server 10.3 and is now removed. Instead of using this deprecated driver, you should use the Oracle Thin Driver that is provided with WebLogic Server. For details about the Oracle Thin Driver, see "JDBC Drivers Installed with WebLogic Server" in Administering JDBC Data Sources for Oracle WebLogic Server.

• The Sybase JConnect 5.5 and 6.0 drivers 5.5 and 6.0 are removed from WebLogic Server as of release 10.3.3 due to an Oracle security policy regarding default installation of code samples. You can download the driver from Sybase or you can use the Oracle-branded JDBC driver for Sybase that is packaged with WebLogic Server.

Changes to weblogic.jms.extension API

As of WebLogic Server 10.3.3, the following internal methods of the weblogic.jms.extensions.WLMessage interface have been removed from the Java API Reference for Oracle WebLogic Server:

public void setSAFSequenceName(String safSequenceName);
public String getSAFSequenceName();
public void setSAFSeqNumber(long seqNumber);
public long getSAFSeqNumber();

Your applications should not use these internal methods. Internal methods may change or be removed in a future release without notice.

Persistent Store Updates

As of WebLogic Server 10.3.3, WebLogic File Store behavior and tuning have changed for default file stores and custom file stores.

Oracle Internet Directory and Oracle Virtual Directory Authentication Providers

Two new LDAP authentication providers were added to WebLogic Server 10.3.2: the Oracle Internet Directory Authentication Provider and the Oracle Virtual Directory Authentication Provider. These authentication providers can store users and groups in, and read users and groups from, the Oracle Internet Directory and Oracle Virtual Directory LDAP servers, respectively.

For information about configuring and using these new security providers, see Configuring LDAP Authentication Providers in Administering Security for Oracle WebLogic Server.

capacityIncrement Attribute

In WebLogic Server 10.3.1 and higher releases, the capacityIncrement attribute is no longer configurable and is set to a value of 1.

Middleware Home Directory

As of WebLogic Server 10.3.1, the notion of the BEA Home directory is replaced by the Middleware Home. The default path of this directory is <drive:>Oracle/Middleware. This change has the following impact on WebLogic Server:

• A new environment variable is introduced in several WebLogic scripts in 10.3.1 to represent the Middleware Home directory: MW_HOME. The directory to which this variable is set generally is the same as BEA_HOME, which is also still used in WebLogic Server scripts.

• By default, the WebLogic Server installation program selects <drive:>Oracle/Middleware as the root product installation directory. However, if a directory containing an existing WebLogic Server installation is detected, that directory is selected instead by default.

• The WebLogic Server 10.3.1 documentation now uses the term Middleware Home, instead of BEA Home. However, this revision is functionally only a change in terminology and does not imply that any WebLogic software, custom domains, or applications must be moved, or that any existing environment variables that represent those locations must be changed.

This change does not affect any existing WebLogic Server installations, custom domains, applications, or scripts on your computer. You may continue to use the BEA_HOME environment variable as before.

Resource Registration Name

As of WebLogic Server 10.3.1, the behavior of the resource registration name for XA data source configurations has changed. In previous releases, the JTA registration name was simply the name of the data source. Now, the registration name is a combination of data source name and domain.

For more information, see Registering an XAResource to Participate in Transactions in Developing JTA Applications for Oracle WebLogic Server.

Servlet Path Mapping

As of version 2.3 of the Java Servlet Specification, the following syntax is used to define mappings:

• A servlet path string that contains only the / (slash) character indicates the default servlet of the application. The servlet path resolves to the request URI minus the context path; in this case, the path resolves to null.

• A String that begins with an * (asterisk) specifies an extension mapping.

These changes introduce a change in behavior with the following HttpServletRequest methods:

• getPathInfo

• getServletPath

To better illustrate the change in behavior, consider the request /abc/def.html that resolves to ServletA:

• If / maps to ServletA, then servletPath="abc/def.html" and pathInfo=null.

• If /* maps to ServletA, then servletPath="" and pathInfo="abc/def.html".

To ensure that the path info returned is non-null, replace all occurrences of the / (slash) servlet mapping string with /*.

The Java Servlet Specification can be downloaded from the following location:

http://www.oracle.com/technetwork/java/javaee/servlet/index.html