Skip Headers
Oracle® Fusion Middleware Upgrade Guide for Oracle WebLogic Server
12c Release 1 (12.1.1)

Part Number E24497-03
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

A WebLogic Server 12.1.1 Compatibility with Previous Releases

This section describes important compatibility information that you should consider before upgrading to WebLogic Server 12.1.1.

See also "WebLogic Server Compatibility" in Understanding Oracle WebLogic Server and What's New in Oracle WebLogic Server for this and prior releases.

Compatibility considerations are provided in the following sections. In all cases, you should refer to:

The remaining sections that apply to your situation depend on the WebLogic Server version from which you are upgrading to WebLogic Server 12.1.1. 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 That Apply to Upgrades From Each WebLogic Server Version

WebLogic Server Version Refer to These Sections

10.3.5

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

Session Affinity Policy

Connection Labeling

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 row, 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

All sections in the above rows, plus:

capacityIncrement Attribute

Middleware Home Directory

Resource Registration Name

10.0

All sections in the above rows, plus:

SAML 2.0 Providers

RDBMS Security Store

Updated WebLogic-branded Data Direct Drivers

Console Configuration Features

SNMP MIB Refresh Interval and Server Status Check Interval No Longer Used

9.2

All sections in the above rows, plus:

Windows NT Authentication Provider Deprecated

Backward Compatibility Flags

JMX 1.2 Implementation

9.1

All sections in the above rows, plus:

SAML V2 Providers

BASIC Authentication with Unsecured Resources

WebLogic Administration and Configuration Scripts

9.0

All sections in the above rows, plus:

XACML Security Providers

Servlet Path Mapping

8.1

All sections in the above rows, plus:

Security MBeans

Password Encryption

Security for HTTP Requests

Secure Access to MBeanHome

Message-Level Security in Web Services

Modular Configuration and Deployment of JMS Resources

JMS Message ID Format

Improved Message Paging

JTA Transaction Log Migration

Administration Console Extension Architecture

Dynamic Configuration Management

Modular Configuration and Deployment of JDBC Resources

Thread Management

XML Implementation

XMLBeans and XQuery Implementation

Deployment Descriptor Validation and Conversion

Deprecated Startup and Shutdown Classes

Resource Adapters

WLEC


Deprecated Functionality

Information about deprecated functionality for WebLogic Server can be found on My Oracle Support at https://support.oracle.com/.

Backward Compatibility Flags

The configuration flags in Table A-2 are available to support backward compatibility when you upgrade a domain. By default, these flags are set to support backward compatibility, unless you disable them by selecting the Do not set backward compatibility flags option during an upgrade, as described in Upgrading a Domain in Graphical Mode.

Table A-2 Backward Compatibility Flags

Category Backward Compatibility Flag For more information, see ...

Security

  • EnforceStrictURLPattern—Specifies whether the server should enforce strict adherence of URL patterns to the Servlet 2.4 specification. During an upgrade, this flag is set to false for backward compatibility.

  • WebAppFilesCaseInsensitive—Specifies whether the URL-pattern matching behavior is case-insensitive for security constraints, servlets, filters, virtual hosts, and so on, in the Webapp container and external security policies. During an upgrade, this flag is set to os, which sets URL-pattern matching as case-sensitive on all platforms except Windows, for compatibility with pre-9.0 releases. As of WebLogic Server 9.0, URL-pattern matching is strictly enforced across operating systems

"SecurityConfigurationMBean"

Web Application

  • backward-compatible—Specifies which JSP version is supported. Depending on the version of the Web application (version 2.4 or 2.5) and the setting of the backward-compatible element, WebLogic Server 12.1.1 supports JSP 2.1 or JSP 2.0.

    backward-compatible is located within the "jsp-descriptor" element, as described in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.

  • AllowAllRoles—Specifies that a wildcard (*) character can be used to set the role name to enable all users/roles in the realm to have access to the resource collection. As of WebLogic Server 9.0, if you specify the wildcard (*) character as the role name, all users/roles in the Web application have access to the resource collection.

  • FilterDispatchedRequestsEnabled—Specifies whether to apply filters to dispatched requests. As of WebLogic Server 9.0, the new Dispatcher element makes this behavior explicit.

  • JSPCompilerBackwardsCompatible—Specifies whether to allow JSPs that do not comply with the JSP 2.0 specification.

  • ReloginEnabled—Specifies whether to allow users multiple attempts to log in to a Web page if the original credentials were not supported. As of WebLogic Server 9.0, the FORM/BASIC authentication behavior has been modified to return the 403 (FORBIDDEN) Web page.

  • RtexprvalueJspParamName—Specifies whether to allow run-time expression values for the JSP <param name> tag. As of WebLogic Server 9.0, the JSP Compiler no longer allows run-time expression values.

"WebAppContainerMBean"


JVM Settings

When upgrading a WebLogic Server 11g or earlier domain to a WebLogic Server 12.1.1 domain, you may have to:

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.dir parameter in the Managed Server startup command.

startWeblogic.sh -Djava.endorsed.dir=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 Administration Console. If using the 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 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, either using WLST or the Administration Console. If using the 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 Administration Console.

startWeblogic.sh -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.1 will need to be updated. For more information, see "Updating Applications to Overcome Conflicts" in Programming WebLogic Enterprise JavaBeans, Version 3.0 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 Programming WebLogic Enterprise JavaBeans, Version 3.0 for Oracle WebLogic Server.

As of WebLogic Server 10.3.2, you can leverage the features of Oracle TopLink with your EJB 3.0 applications. Oracle TopLink is an advanced, object-persistence and object-transformation framework that provides development tools and run-time capabilities that reduce development and maintenance efforts, and increase enterprise application functionality. For more information, see Oracle Fusion Middleware Developer's Guide for Oracle TopLink.

Web Services

This section describes Web services features that have been removed from WebLogic Server 12.1.1, as well as new Web services features that were added in WebLogic Server 10.3.3 or greater.

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.

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

Security

This section describes security changes that have been made over various WebLogic Server releases.

SSL Support Changes

This section describes SSL changes that have been made over various WebLogic Server versions.

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 "Configuring SSL" in Securing Oracle WebLogic Server.

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:

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 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 Securing Oracle WebLogic Server for additional information.

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 Securing Oracle WebLogic Server.

SAML 2.0 Providers

For SAML 2.0 support, the SAML 2.0 Credential Mapping provider and SAML 2.0 Identity Assertion provider were added in WebLogic Server 10.3. These new providers can be used, respectively, to generate and consume SAML 2.0 assertions in the following use cases:

  • SAML 2.0 Web Single Sign-On Profile

  • WS-Security SAML Token Profile version 1.1

For SAML 2.0 Web Single Sign-On, the assertions generated by the SAML 2.0 Credential Mapping provider may be consumed only by the SAML 2.0 Identity Assertion provider. They are not compatible with SAML 1.1 assertions.

SAML Token Profile 1.1 is supported by WebLogic Server Web Services as of Release 10.3. This feature includes support for SAML 2.0 and SAML 1.1 assertions, and is backward compatible with SAML Token Profile 1.0 SAML tokens are configured for a Web Service through use of the appropriate WS-SecurityPolicy assertions.

Note:

SAML Token Profile 1.1 is supported only through WS-SecurityPolicy. The earlier "WebLogic Server 9.2 Security Policy" supports SAML Token Profile 1.0/SAML 1.1 only.

RDBMS Security Store

WebLogic Server 10.3 added the option of using an external RDBMS as a data store that is used by the following security providers:

  • XACML Authorization provider

  • XACML Role Mapping provider

  • The following providers for SAML 1.1:

    • SAML Identity Assertion provider V2

    • SAML Credential Mapping provider V2

  • The following providers for SAML 2.0:

    • SAML 2.0 Identity Assertion provider

    • SAML 2.0 Credential Mapping provider

  • WebLogic Credential Mapping provider

  • PKI Credential Mapping provider

  • Certificate Registry

This data store, called the RDBMS security store, is strongly recommended for the use of SAML 2.0 services in two or more WebLogic Server instances in that domain, such as in a cluster. When the RDBMS security store is configured in a domain, an instance of any of the preceding security providers that has been created in the security realm automatically uses only the RDBMS security store as a data store, and not the embedded LDAP server. WebLogic security providers configured in the domain that are not among those in the preceding list continue to use their respective default stores; for example, the WebLogic Authentication provider continues to use the embedded LDAP server.

In order to use the RDBMS security store, the preferred approach is first to create a domain in which the external RDBMS server is configured. Before you boot the domain, create the tables in the data store that are required by the RDBMS security store. The WebLogic Server installation directory contains a set of SQL scripts that create these tables for each supported database.

If you have an existing domain in which you want to use the RDBMS security store, you should create the new domain, then migrate your security realm to it. Oracle does not recommend "retrofitting" the RDBMS security store to an existing domain. For more information, see "Managing the RDBMS Security Store" in Securing Oracle WebLogic Server.

Windows NT Authentication Provider Deprecated

The Windows NT Authentication provider is deprecated as of WebLogic Server 10.0. Use one or more of the other supported Authentication providers instead.

SAML V2 Providers

For SAML 1.1 support, new versions of the SAML Credential Mapping provider and SAML Identity Assertion provider were added in WebLogic Server 9.2. The SAML Credential Mapping V1 provider and SAML Identity Assertion V1 provider are deprecated; you should use the V2 versions of the SAML Credential Mapping and SAML Identity Assertion providers.

Although the version number of the providers has been incremented to V2, the new SAML security providers implement the SAML 1.1 standard, as did the V1 providers.

Note:

For web single sign-on, the SAML 1.1 providers described in this section are not compatible with a WebLogic Server instance that has been configured with SAML 2.0 services.

XACML Security Providers

As of 9.1, WebLogic Server includes two new security providers, the XACML Authorization provider and the XACML Role Mapping provider. Previous releases of WebLogic Server used an authorization provider and a role mapping provider based on a proprietary security policy language. These XACML security providers support the eXtensible Access Control Markup Language (XACML) 2.0 standard from OASIS. These providers can import, export, persist, and execute policy expressed using all standard XACML 2.0 functions, attributes, and schema elements.

WebLogic domains created using WebLogic Server 9.1 and later include the XACML providers by default. The new XACML providers are fully compatible with policies and roles created using the WebLogic Authorization provider (DefaultAuthorizer) and WebLogic Role Mapping provider (DefaultRoleMapper). Existing WebLogic domains that you upgrade to 12.1.1 continue to use the authorization and role mapping providers currently specified, such as third-party partner providers or the original WebLogic Authorization and Role Mapping providers. If you want, you can migrate existing domains from using WebLogic Server proprietary providers to the XACML providers, including performing bulk imports of existing policies. For more information, see "Understanding WebLogic Server Security" in Understanding Oracle WebLogic Server.

Security MBeans

Table A-3 lists the changes to security MBeans as of WebLogic Server 9.0.

Table A-3 Changes to Security MBeans as of WebLogic Server 9.0

Type of Security MBean Description

All security MBeans

In WebLogic Server 8.1, when you updated a security MBean attribute, the values were available to the security configuration and management hierarchy immediately, and to the security run-time hierarchy following a server reboot.

As of WebLogic Server 9.0, whether a security MBean attribute change is effective and available to the configuration, management, and run-time hierarchies immediately or upon server reboot is controlled by setting that attribute as dynamic or non-dynamic. For more information, see Dynamic Configuration Management.

RealmMBean, UserLockoutManagerMBean, and all security provider MBeans

  • The wls_getDisplay method is deprecated. In its place, you should use the new getName method. In addition, the following security methods have been removed:

    wls_getAttributeTag
    wls_getConstructorTag
    wls_getMBeanTag
    wls_getNotificationTag
    wls_getOperationTag
    
  • The weblogic.Admin tools and pre-9.2 JMX security APIs can no longer be used to configure security MBeans. These utilities and APIs can still be used, however, to view and invoke methods on the security MBeans.

For security provider MBeans (only):

  • When adding or removing a security provider, you must reboot the server before any changes take effect.

  • When modifying an existing security provider, if you modify any non-dynamic attributes, the server must be rebooted before any (that is, non-dynamic or dynamic) changes take effect. For more information, see Dynamic Configuration Management.

All custom security provider MBeans

  • By default, all custom security provider MBeans attributes are non-dynamic. For more information, see Dynamic Configuration Management.

  • You can set an MBean attribute to be dynamic by setting Dynamic="true" for the attribute within the MDF file. For example:

    <MBeanAttribute
    Name        = "Foo"
    Type        = "java.lang.String"
    Dynamic = "true"
    Description = "Specifies that this attribute is a dummy."
    />
    

Password Encryption

To prevent unauthorized access to sensitive data such as passwords, some attributes in configuration MBeans are encrypted. The attributes persist their values in the domain configuration files as an encrypted string. For further security, the in-memory value is stored in the form of an encrypted byte array to help reduce the risk of the password being snooped from memory.

In pre-9.0 releases, you could edit the config.xml file to specify an encrypted attribute, such as a password, in clear-text or encrypted format. In this case, when booted, the WebLogic Server encrypts the information the next time it writes to the file.

As of WebLogic Server 9.0, when operating in production mode, the password of an encrypted attribute must be encrypted in the configuration files. In development mode, the password of an encrypted attribute can be either encrypted or clear-text.

You can use the weblogic.security.Encrypt command-line utility to encrypt the passwords, as follows:

java weblogic.security.Encrypt

You are prompted to enter a password, and the command returns the encrypted version. Then, copy the encrypted password returned into the appropriate file.

This utility is not just used for passwords in the configuration files. It can also be used to encrypt passwords in descriptor files (for example, a JDBC or JMS descriptor) and in deployment plans. For more information, see "encrypt" in Command Reference for Oracle WebLogic Server.

Security for HTTP Requests

By default, when an instance of WebLogic Server responds to an HTTP request, its HTTP response header does not include the WebLogic Server name and version number. This behavior is different from releases before WebLogic Server 9.0.

To have the name and version number included in the HTTP response header when responding to an HTTP request, enable the Send Server Header attribute for the WebLogic Server instance in the Administration Console. The attribute is located on the Server > ServerName > Protocols > HTTP tab under the Advanced Options section. Note that enabling this feature may creates a security risk if a possible attacker knows about a vulnerability in the specified version of WebLogic Server.

For more information about ensuring security, see "Securing the WebLogic Security Service" in "Ensuring the Security of Your Production Environment" in Securing a Production Environment for Oracle WebLogic Server.

Secure Access to MBeanHome

In pre-9.0 releases of WebLogic Server, anonymous access to MBeanHome was enabled by default. With the security enhancements delivered as of WebLogic Server 9.0, anonymous access to MBeanHome is no longer allowed.

Although doing so is not recommended, you can re-enable anonymous access by specifying the following flag when starting the server:

-Dweblogic.management.anonymousAdminLookupEnabled

Message-Level Security in Web Services

As of WebLogic Server 9.0, message-level security in Web Services was enhanced to use the standards-based Web Services Policy Framework (WS-Policy). WS-Policy provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web Services-based system. For more information about WS-Policy, see "Using WS-SecurityPolicy 1.2 Policy Files" in Security and Administrator's Guide for Web Services.

In 8.1, the implementation was based on an OASIS implementation of the Web Services Security (WSS) standard. This implementation is supported for backward compatibility, but is deprecated as of 9.0. For more information, see http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss.

Web Applications, JSPs, and Servlets

The following sections provide important compatibility information for Web applications, JSPs, and Servlets in WebLogic Server 12.1.1:

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.

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

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.

Backward Compatibility Flags

For WebLogic Server 10.0 and later, backward compatibility for WebLogic Server 9.2 or earlier is supported by using the backward-compatible element within the jsp-descriptor element, as described in this section and in "jsp-descriptor" in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.

JSP 2.1 Support and Compatibility With JSP 2.0 Web Applications

JSP 2.1 is supported as of WebLogic Server 10.0. Depending on the version of the Web application (version 2.4 or 2.5) and the setting of the backward-compatible element, WebLogic Server 10.0 and later also supports JSP 2.0.

See "Backward Compatibility Flags" in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server for important information about the buffer suffix setting and implicit servlet 2.5 package imports.

Support for JSP 2.0

JSP 2.0 was supported as of WebLogic Server 9.0, and continues to be supported as described in Backward Compatibility Flags. Please note the following changes to the JSP behavior as required in support of JSP 2.0:

  • If a JSP does not participate in a session (or if the session in which a JSP participates is invalid), an IllegalStateException is thrown when the following command is executed:

    PageContext.getAttribute(name, PageContext.SESSION_SCOPE)
    

    If you are not concerned about this type of error, you can catch and ignore it.

  • JspWriterImpl now replaces \n with System.getProperty("line.separator") for each printline function. This replacement causes problems with JSPs that:

    • Contain multiple page directives that appear on new lines. For example:

      <%@ page import="com.foo.bar.*" %>
      <%@ page import="com.foo.xyz.*" %>
      ...
      
    • Generate output in XML format.

    • Generate an XML declaration following the page directives.

    • Are served by Windows systems. In this case, \r\n is output for each page directive.

    • Are viewed using Internet Explorer.

      When viewed in Internet Explorer, each page directive outputs an empty \r\n and the XML declaration (<?xml version="1.0" encoding="iso-8859-1"?>) appears after every new line. Internet Explorer displays an error message indicating that it cannot locate the declaration and that the page cannot be viewed, even though it can be compiled.

    To work around any issues caused by changes to JspWriterImpl, you can perform one or both of the following tasks:

    • Define the XML declaration at the top of the page.

    • Group the page directives into a single declaration, for example:

      <%@ page import="com.foo.bar.*, com.foo.baz.*"
      contentType="text/html" pageEncoding="UTF-8" errorPage="Error.jsp" %> 
      
  • The JSP <param name> tag no longer allows run-time expression values. For example:

    <jsp:param name="<%= AdminActions.RETURN_LINK %>" value="<%= returnlink %>" />
    

    You can continue to support this feature by disabling the Do not set backward compatibility flags upgrade option during the domain upgrade, as described in the "Select Upgrade Options" row of Table 5-1, or enabling the backwardCompatible flag in the weblogic.xml file, as follows:

    <jsp-descriptor>
    <jsp-param> 
    <param-name>backwardCompatible</param-name>
    <param-value>true</param-value> 
    </jsp-param> 
    </jsp-descriptor> 
    

BASIC Authentication with Unsecured Resources

For WebLogic Server versions 9.2 and later, client requests that use HTTP BASIC authentication must pass WebLogic Server authentication, even if access control is not enabled on the target resource.

The setting of the Security Configuration MBean flag "enforce-valid-basic-auth-credentials" determines this behavior. (The DomainMBean can return the new Security Configuration MBean for the domain.) It specifies whether the system should allow requests with invalid HTTP BASIC authentication credentials to access unsecured resources.

Note:

The Security Configuration MBean provides domain-wide security configuration information. The enforce-valid-basic-auth-credentials flag effects the entire domain.

The enforce-valid-basic-auth-credentials flag is true by default, and WebLogic Server authentication is performed. If authentication fails, the request is rejected. WebLogic Server must therefore have knowledge of the user and password.

See "Understanding BASIC Authentication with Unsecured Resources" in Programming Security for Oracle WebLogic Server for complete information.

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

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.

JDBC Feature Changes

The following sections describe changes to JDBC support:

For details about new JDBC features, see "JDBC" in What's New in Oracle WebLogic Server.

Data Source Profile Logging

To provide better usability and performance, WebLogic Server 12.1.1 and higher uses a data source profile log to store events. See "Monitoring WebLogic JDBC Resources" in Configuring and Managing JDBC Data Sources for Oracle WebLogic Server.

Session Affinity Policy

In WebLogic Server 12.1.1, GridLink data sources use the session affinity policy to improve performance by directing the database operations of a servlet session to the same RAC instance in a RAC cluster. See "GridLink Affinity" in Configuring and Managing JDBC Data Sources for Oracle WebLogic Server.

Connection Labeling

In WebLogic Server 12.1.1, labeling allows an application to attach arbitrary name/value pairs (labels) to a connection that has a particular initialization state. This allows the application to improve performance by minimizing the time and cost of re-initializing a connection. See "Labeling Connections" in Configuring and Managing JDBC Data Sources for Oracle WebLogic Server.

ONS Debugging

In WebLogic Server 12.1.1, UCP and ONS are no longer included in your installation. For information on how to set UPC and ONS debugging, see "Setting Debugging for UCP/ONS" in Configuring and Managing JDBC Data Sources for Oracle WebLogic Server.

Oracle Type 4 JDBC drivers from DataDirect

As of WebLogic Server 12.1.1, Oracle Type 4 JDBC drivers from DataDirect are referred to as WebLogic-branded DataDirect drivers. Oracle has retired the documentation in 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 Programming JDBC for Oracle WebLogic Server. Oracle recommends reviewing DataDirect documentation for detailed information on driver behavior, see "Progress DataDirect for JDBC User's Guide Release 4.2" and "Progress DataDirect for JDBC Reference Release 4.2" at http://www.datadirect.com/index.html.

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 "Using Third-Party JDBC Drivers with WebLogic Server" in Type 4 JDBC Drivers 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.

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.

JDBC 4.0 Support

As of 10.3, WebLogic Server is compliant with the JDBC 4.0 specification, with the following enhancements and exceptions:

  • SQLXML is fully supported on the server side. On the RMI client side, SQLXML is partially supported. You cannot use the getSource and setResult APIs on the client side.

  • WebLogic Server JDBC supports standard Wrapper Pattern functionality and extends the functionality on the server side. The JDBC standard requires support for the Wrapper operation on the interface. WebLogic Server supports the Wrapper operation on both the interface and on the concrete class on the server side.

  • WebLogic Server enhances statement pool management as follows.

    • For the Statement interface:

      • Call isPoolable() always returns false

      • Call setPoolable() does not change the poolable state.

    • For the PreparedStatement and CallableStatement interfaces:

      • Call isPoolable() returns the current poolable state, the default value is true

      • Call setPoolable() modifies the poolable state.

    • For the PreparedStatement or CallableStatement interface, the following occurs when you call the close() method:

      • If the current poolable state is false, PreparedStatement or CallableStatement is closed.

      • If the current poolable state is true, PreparedStatement or CallableStatement reverts to the statement cache.

  • Updated third-party JDBC drivers:

    • Oracle Thin driver updated from 10g to 11g

    • PointBase database server and driver updated from 5.1 to 5.7

Updated WebLogic-branded Data Direct Drivers

The WebLogic-branded Data Direct JDBC drivers included with WebLogic Server are provided from DataDirect. As of 10.3, the drivers were updated to DataDirect Version 3.7. For information about changes to these drivers, including to support JDBC 4.0, see "Using WebLogic-branded DataDirect Drivers" in the Programming JDBC for Oracle WebLogic Server.

JMS

Note the following changes to JMS:

Default Message Mode Has Changed

As of WebLogic Server 12.1.1, the default messaging mode has been changed from multicast to unicast.

Modular Configuration and Deployment of JMS Resources

As of WebLogic Server 9.0, JMS configurations are stored as modules, defined by XML documents that conform to the new weblogic-jmsmd.xsd schema. With modular deployment of JMS resources, you can promote your application and the JMS configuration from one environment to another. For example, you can promote your application and the required JMS configuration from a testing environment to a production environment, without opening an EAR file and without extensive manual JMS reconfiguration.

For more information, see:

The WebLogic Upgrade Wizard automatically converts pre-9.0 JMS resources to a JMS Interop module file named interop-jms.xml, which is copied to the domain's config\jms directory. For more information, see "JMS Interop Modules" in Configuring and Managing JMS for Oracle WebLogic Server.

Please note the following JMS configuration changes:

  • When generating new JMS resources, you must define all attributes in the JMS module (that is, not using the pre-9.0 configuration file).

  • The Allow Persistent Downgrade option enables you to specify whether JMS clients receive an exception when they send persistent messages to a destination targeted to a JMS server that does not have a persistent store configured. This option is provided for backward compatibility with previous releases.

    By default, the option is set to false, specifying that clients receive an exception when they send persistent messages to a JMS server for which no store is configured. When the option is set to true, persistent messages are downgraded to non-persistent, but, the send operations are allowed to continue. This parameter is effective only when the Store Enabled parameter is disabled (that is, when it is set to false).

    For more information, see "AllowsPersistentDowngrade" in "JMSServerBean" in Oracle WebLogic Server MBean Reference.

  • A Temporary Template is created, by default, for JMS Servers. In previous releases, no default template was provided. You can also configure a temporary template, using the JMS server's Temporary Template attribute.

    You can control whether the JMS Server can host a temporary destination by setting the Hosts Temporary Destinations attribute. In previous releases, a JMS Server was enabled to host temporary destinations if and only if the TemporaryTemplate attribute was set.

  • JMS templates specified for distributed destinations are no longer supported as of WebLogic Server 9.0, and they are ignored. As of WebLogic Server 9.0, this functionality is replaced by uniform distributed destinations. For more information, see "Creating Uniform Distributed Destinations" in Configuring and Managing JMS for Oracle WebLogic Server.

  • The AllowCloseInOnMessage attribute for JMS Connection Factories is enabled by default. For more information, see "ClientParamsBean" in Oracle WebLogic Server MBean Reference.

  • The getExpirationLoggingPolicy attribute in the DeliveryFailureParamsBean has been deprecated. Oracle recommends that you update your applications to use the Message Life Cycle Logging feature described in "Message Life Cycle Logging" in Configuring and Managing JMS for Oracle WebLogic Server. It should also be noted that the getExpirationLoggingPolicy attribute now removes any leading and trailing white space that may have been embedded in an application.

JMS Message ID Format

As of WebLogic Server 9.0, the format of the JMS message ID has changed. Oracle continues to support the pre-9.0 format for existing consumers, producers, and servers. For example, existing JMS consumers may continue to view messages in the pre-9.0 format, even when received from a new JMS producer and JMS server.

Improved Message Paging

As of WebLogic Server 9.0, the message paging feature for freeing up JVM heap space during peak message load situations is always enabled on JMS servers. Additionally administrators are not required to create a dedicated message paging store because paged out messages can be stored in a directory on your file system. However, for the best performance you should specify that messages be paged to a directory other than the one used by the JMS server's persistent store.

See "Paging Out Messages To Free Up Memory" in Performance and Tuning for Oracle WebLogic Server.

Messaging

This section describes messages changes that you should be aware of when upgrading to WebLogic Server 12.1.1.

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 Oracle WebLogic Server API Reference:

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.

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:

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.

JTA

The following sections describe JTA feature changes:

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 Programming JTA for Oracle WebLogic Server.

JTA Transaction Log Migration

All JTA domain configuration options are persisted from the legacy configuration file. The only changes are at the server level. As of WebLogic Server 9.0, the Transaction Manager uses the default WebLogic persistent store to store transaction log records. During the upgrade, the Upgrade Wizard copies transaction log records to the default store. The transaction log file prefix from the existing server configuration is used only to locate the transaction log (.tlog) files during an upgrade; it is not preserved after the upgrade.

If the entire domain resides on a single computer, the Upgrade Wizard handles the upgrade (and copies transaction log records to the default store) for all Managed Servers during the initial domain upgrade. If Managed Servers reside on separate machines, you must upgrade each Managed Server individually, as described in Upgrade Your Application Environment.

Please note the following:

If you have put your transaction log files in network storage in preparation for Transaction Recovery Service migration, the log file location is not preserved after the upgrade. In this release, the WebLogic Server Transaction Manager uses the WebLogic default persistent store to store transaction log files. You can achieve the same result by moving the location of the WebLogic default persistent store to a network location. Note that you must manually copy the DAT file from the default location of the current default store to the new location of the default store.

If transactions span multiple domains, you must configure your domain to enable inter-domain transactions. For more information, see "Configuring Domains for Inter-Domain Transactions" in Programming JTA for Oracle WebLogic Server.

Administration Console

The following sections describe changes to the Administration Console:

Console Configuration Features

WebLogic Server 10.3 introduced new options that were added for configuring Console behavior, including the ability to do the following:

  • Lock a domain configuration so you can make changes to the configuration while preventing other accounts from making changes during your edit session

  • Specify whether to deploy internal applications such as the Administration Console, UDDI, and the UDDI Explorer on demand (upon first access) instead of during server startup

  • Locate any WebLogic Server Configuration MBean that contains the string specified in its name, using a new search feature added to the banner toolbar region

  • Use additional capabilities for automatically migrating failed servers and services from one server to another

  • Deploy and control Service Component Architecture (SCA) deployments

  • Inspect Spring applications

For more information, see "What's New in WebLogic Server" in the WebLogic Server 10.3 Release Notes.

Administration Console Extension Architecture

In WebLogic Server version 9.0, the Administration Console was built on the WebLogic Portal Framework, which makes it more open and more readily extensible. The architecture necessitated new procedures for extending the Administration Console. WebLogic Server console extensions built for releases of WebLogic Server before 9.0 do not function with the new console infrastructure.

The following features were added in WebLogic Server 10.3.2:

  • A sample Look and Feel is provided, which you can modify to create a custom Look and Feel for the WebLogic Server Administration Console.

  • Online help can be created and associated with console extensions.

For more information about extending the WebLogic Server Administration Console, see Extending the Administration Console for Oracle WebLogic Server.

Important Console-Extension Information for Version 9.2

Version 9.2 of WebLogic Server introduced the following changes to console extensions:

  • Before this release, Administration Console extensions could import a set of third-party JSP tag libraries by specifying a path name to the tag library file. For example,

    <%@ taglib uri="/WEB-INF/beehive-netui-tags-template.tld" prefix="beehive-template" %> 
    

    As of 10.0, Administration Console extensions that use these third-party JSP tag libraries from the WebLogic Server installation must use pre-defined, absolute URIs to specify the tag libraries. For example:

    <%@ taglib uri="http://beehive.apache.org/netui/tags-template-1.0" prefix="beehive-template" %> 
    

    The Administration Console's web.xml file maps these URIs to tag libraries within the WebLogic Server installation. This mapping facility enables Oracle to reorganize its installation directory without requiring you to change your JSPs.

    Any Administration Console extensions that use the old path name syntax to import Apache Struts, Apache Beehive, or the JSTL tag libraries must update all path names to the new URIs.

    The URI for the WebLogic Server Console Extension tag library (console-html.tld) remains unchanged: /WEB-INF/console-html.tld.

    For more information, see "JSP Templates and Tag Libraries" in Extending the Administration Console for Oracle WebLogic Server.

  • By convention, portal include files (.pinc) files are now called portal book files (.book).

WebLogic Portal Skeleton URI References Should be Fully Qualified

WebLogic Portal requires that any explicit Skeleton URI references be fully qualified relative to the webapp. However, the documentation and some console extension examples have sometimes used relative references to these skeletons. Consider the following incorrect example:

<netuix:singleLevelMenu markupType="Menu" markupName="singleLevelMenu" skeletonUri="singlelevelmenu_children2.jsp"/>

This example should have been correctly specified as:

<netuix:singleLevelMenu markupType="Menu" markupName="singleLevelMenu" skeletonUri="/framework/skeletons/default/singlelevelmenu_children2.jsp"/>

For this release, relative skeleton URI references continue to work. However, any console extensions that you have written should be updated to use fully qualified skeleton URIs, because these relative references may no longer function correctly in a future release.

SNMP MIB Refresh Interval and Server Status Check Interval No Longer Used

The "SNMPAgentMBean" MBean "MibDataRefreshInterval" and "ServerStatusCheckIntervalFactor" attributes were deprecated in WebLogic Server 10.0 and are ignored.

JMX 1.2 Implementation

As of WebLogic Server 9.0, WebLogic Server uses the Java Management Extensions (JMX) 1.2 implementation that is included in JDK 5.0. Before 9.0, WebLogic Server used its own JMX implementation based on the JMX 1.0 specification.

The JMX 1.2 reference implementation introduces serialization incompatibilities. Despite these incompatibilities in the reference implementation, JMX clients created for WebLogic Server 8.1 can be used with 9.2 and later releases as follows:

Oracle recommends that you update your JMX clients to be compliant with WebLogic Server 12.1.1. Before 9.0, WebLogic Server supported a typed API layer over its JMX layer. It was possible for your JMX application classes to import type-safe interfaces for WebLogic Server MBeans, retrieve a reference to the MBeans through the weblogic.management.MBeanHome interface, and invoke the MBean methods directly.

JMX Deprecated Features

As of 9.0, the MBeanHome interface is deprecated. Instead of using this API-like programming model, all JMX applications should use the standard JMX programming model, in which clients use the javax.management.MBeanServerConnection interface to discover MBeans, attributes, and attribute types at run time. In this JMX model, clients interact indirectly with MBeans through the MBeanServerConnection interface.

If any of your classes import the type-safe interfaces (available under weblogic.management), Oracle recommends that you update them to use the standard JMX programming model. For more information, see "Understanding WebLogic Server MBeans" in Developing Custom Management Utilities With JMX for Oracle WebLogic Server.

WebLogic Administration and Configuration Scripts

Due to changes with the MBean hierarchy, Oracle does not guarantee that pre-9.2 configuration and administration scripts (such as WLST, wlconfig, weblogic.Admin, Ant, and so on) run in 12.1.1. Oracle recommends that you update your scripts to take advantage of the new features provided in WebLogic Server in version 9.2 and later. For more information about new features and changes in the MBean hierarchy, see the documents listed in Table A-4:

Table A-4 New Features in WebLogic Server by Release

For the following release . . . . . . see the following for a description of new features

9.2

"What's New in WebLogic Server 9.2" at:

http://download.oracle.com/docs/cd/E13222_01/wls/docs92/notes/new.html

10.0

"What's New in WebLogic Server 10.0" at:

http://download.oracle.com/docs/cd/E13222_01/wls/docs100/notes/new.html

10.3

"What's New in WebLogic Server" for version 10.3 at:

http://download.oracle.com/docs/cd/E12840_01/wls/docs103/notes/new.html

10.3.1

What's New in Oracle WebLogic Server for 11g Release 1 (10.3.1) at:

http://download.oracle.com/docs/cd/E12839_01/web.1111/e13852/toc.htm

10.3.2

What's New in Oracle WebLogic Server for 11g Release 1 (10.3.2) at:

http://download.oracle.com/docs/cd/E15523_01/web.1111/e13852/toc.htm

10.3.3

What's New in Oracle WebLogic Server for 11g Release 1 (10.3.3) at:

http://download.oracle.com/docs/cd/E14571_01/web.1111/e13852/toc.htm

10.3.4

What's New in Oracle WebLogic Server for 11g Release 1 (10.3.4) at:

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13852/toc.htm

12.1.1

What's New in Oracle WebLogic Server for 12c Release 1 (12.1.1) at:

http://download.oracle.com/docs/cd/E24329_01/web.1211/e24494/toc.htm


For additional information about upgrading your application infrastructure and the scripting tools that have been deprecated, see Step 1: Upgrade Your Application Infrastructure.

Dynamic Configuration Management

Configuration attributes are classified as dynamic or non-dynamic.

WebLogic Server 9.0 introduced a change management process to provide a secure, predictable means for applying configuration changes in a domain. A batch change mechanism changes the way dynamic changes are applied when they are mixed with non-dynamic changes. Specifically, when a configured server or system resource is affected by a change to a non-dynamic attribute, no other changes (even dynamic changes) take effect, in current or future batches, until after the server or system resource is restarted. In this case, Oracle recommends that you restart the entity as soon as possible after the batch change is completed to ensure the system is in a consistent state and to allow future changes to be accepted.

You should test your configuration scripts to determine whether a non-dynamic change has been applied, and if so, restart the server. To determine whether a change is non-dynamic and requires a server restart:

To determine which security attributes are dynamic or non-dynamic, see "Security Configuration MBeans" in Securing Oracle WebLogic Server.

For more information, see "Managing Configuration Changes" in Understanding Domain Configuration for Oracle WebLogic Server.

Modular Configuration and Deployment of JDBC Resources

As of WebLogic Server 9.0, the number of JDBC resource types was reduced to simplify JDBC configuration and to reduce the likelihood of configuration errors. Now, instead of configuring a JDBC connection pool and then configuring a data source or transactional data source to point to the connection pool and bind to the JNDI tree, you can configure a data source that encompasses a connection pool. For more information about simplified JDBC resource configuration introduced in WebLogic Server 9.0, see "Simplified JDBC Resource Configuration" in Configuring and Managing JDBC Data Sources for Oracle WebLogic Server, available at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jdbc_admin/jdbc_intro.html#simple_res_config.

The WebLogic Upgrade Wizard automatically converts JDBC data sources, connection pools, MultiPools, and data source factories to their new counterparts in WebLogic Server 12.1.1, as described in the following sections:

For information about JDBC features, methods, interfaces, and MBeans that were deprecated as of WebLogic Server 9.0, see "Deprecated JDBC Features, Methods, Interfaces, and MBeans" in the Release Notes, available at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/notes/new.html#deprecated_jdbc_features.

JDBC Data Sources and Connection Pools

The Upgrade Wizard converts legacy JDBC data source/connection pool pairs to two data source system resource modules, one for the data source and one for the connection pool:

  • The data source that replaces the existing data source or transactional data source defines the data source parameters and refers to the second data source for its connection pool and related attributes.

  • The data source that replaces the connection pool contains the JDBC driver parameters, the connection pool parameters, and the XA parameters.

    Note:

    Only data sources that are converted as part of a domain upgrade can refer to another data source for its connection pool. In all other cases, each data source contains its own pool of database connections.

During an upgrade, the Upgrade Wizard sets the GlobalTransactionsProtocol parameter for a data source based on the type of data source being converted (transactional or non-transactional) and the type of driver used in the related connection pool, as noted in Table A-5.

Table A-5 Parameter Settings for Global Transaction Protocol Parameter Setting

Legacy Data Source Type Driver Type Emulate Two-Phase Commit GlobalTransactionProtocol

Tx Data Source

XA

N/A

TwoPhaseCommit

Tx Data Source

Non-XA

False

OnePhaseCommit (by default; not explicitly set)

Tx Data Source

Non-XA

True

EmulateTwoPhaseCommitFoot 1 

Data Source

Non-XA

N/A

None


Footnote 1 Depending on your environment, you may want to consider using the LoggingLastResource (LLR) transaction protocol in place of the EmulateTwoPhaseCommit protocol for transaction processing because of its performance benefits. For more information see "Understanding the Logging Last Resource Transaction Option" in Configuring and Managing JDBC Data Sources for Oracle WebLogic Server.

MultiPools

The Upgrade Wizard converts a MultiPool to a multi-data source, which is another instance of a data source object that provides load balancing or failover between data sources.

Data Source Factories

Data source factories are deprecated as of WebLogic Server 9.0 and are included for backward compatibility only. No conversion of data source factories is required.

Thread Management

Oracle recommends using Work Manager concepts to manage threads because execute queues are no longer the default method used as of WebLogic Server 9.0. You define the rules and constraints for your application by defining a Work Manager and applying it either globally to a WebLogic domain or specifically to an application component. For more information, see "Using Work Managers to Optimize Scheduled Work" in Configuring Server Environments for Oracle WebLogic Server.

In WebLogic Server 8.1, processing was performed in multiple execute queues. If you had been using execute queues to improve performance in 8.1, you may continue to use them after you upgrade your application domains. Oracle provides a use81-style-execute-queues flag that enables you to disable the self-tuning execute pool and provide backward compatibility for upgraded applications to continue to use user-defined execute queues. For information about enabling the backward compatibility flag, and configuring and monitoring execute queues, see "How to Enable the WebLogic 8.1 Thread Pool Model" in WebLogic Server Performance and Tuning for Oracle WebLogic Server.

XML Implementation

Please note the following changes to XML support as of WebLogic Server 9.0:

XMLBeans and XQuery Implementation

As of 9.0, the XMLBean implementation in WebLogic Server has been moved from an internal library (com.bea.xml) to the Apache open source project (org.apache.xmlbeans).

If you used XMLBeans in your WebLogic Server 8.1 applications, you must perform the following steps:

  1. Update the package name used by XMLBeans from com.bea.xml to org.apache.xmlbeans.

  2. Recompile your XMLBean schemas to update the schema metadata (.xsb) files and generated code.

As of 9.0, the XMLQuery (XQuery) implementation conforms to the following specifications:

In WebLogic Server 8.1, the XQuery implementation conformed to XQuery 1.0 and XPath 2.0 Functions and Operators—W3C Working Draft 16 August 2002, available from the W3C Web site at http://www.w3.org/TR/2002/WD-xquery-operators-20020816/. The 2002 XQuery implementation is deprecated as of 9.0.

In most cases, simple XQuery and XPath operations in pre-9.0 code behaves the same in 10.0. To ensure that the XQuery and XPath operations produce the expected results, you can review or update the existing XMLObject.selectPath() and XMLObject.execQuery() method calls using one of the following methods:

As of 9.0, the behavior of XMLCursor.moveXML() has changed. In 8.1, a cursor that was inside a moved fragment remained on the original document. As of 9.0, cursors move with fragments.

Deployment Descriptor Validation and Conversion

This section describes changes in the use of deployment descriptors in a WebLogic Server environment, as of release 9.0:

Deprecated Startup and Shutdown Classes

As of 9.0, application-scoped startup and shutdown classes were deprecated in WebLogic Server, in favor of applications that respond to application lifecycle events. Oracle recommends that you update your application environment to use the lifecycle events in place of application-scoped and domain-level startup and shutdown classes. For more information, see "Programming Application Life Cycle Events" in Developing Applications for Oracle WebLogic Server.

Resource Adapters

Table A-6 lists the configuration settings for resource adapters that are deprecated or no longer supported. For more information about new features and changes, see "What's New in WebLogic Server".

Table A-6 Deprecated or Unsupported Resource Adapter Configuration Settings

This element ... As of WebLogic Server 9.0 ...

Link-Ref Mechanism

This element has been deprecated and replaced by the new Java EE libraries feature. For more information about Java EE libraries, see "Creating Shared J2EE Libraries and Optional Packages" in Developing Applications for Oracle WebLogic Server.

The Link-Ref mechanism is still supported in this release for resource adapters developed under the J2CA 1.0 Specification. For more information about using the Link-Ref mechanism with 1.0 resource adapters, see "(Deprecated) Configuring the Link-Ref Mechanism" in "Configuring the weblogic-ra.xml File" in Programming Resource Adapters for Oracle WebLogic Server.

<shrink-period-minutes>

This element has been deprecated and replaced by <shrink-frequency-seconds>, which you can use to specify the shrink period in increments of seconds, instead of minutes.

The <shrink-frequency-seconds> element overrides the <shrink-period-minutes> element if both are set.

<connection-maxidle-time>

This element has been deprecated and is replaced by <inactive-connection-timeout-seconds>, which you can use to specify the connection timeout in increments of seconds.

The <inactive-connection-timeout-seconds> element overrides the <connection-maxidle-time> element if both are set.

<security-principal-map>

This element is no longer supported; the security principal map is configured using the Administration Console.

You should remove the <security-principal-map> definition from the weblogic-ra.xml file. Otherwise, deployment of the resource adapter fails.

<connection-cleanup-frequency>

This element is no longer supported and is ignored during deployment.

<connection-duration-time>

This element is no longer supported and is ignored during deployment.


WLEC

WLEC was deprecated in WebLogic Server 8.1. WLEC users should move applications to the WebLogic Tuxedo Connector, as described in WebLogic Tuxedo Connector Migration Guide for WLEC to Oracle WebLogic Server.