Upgrading WebLogic Application Environments

Compatibility with Previous Releases

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

Note: See also Compatibility Statement for BEA WebLogic Server 9.0 at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/compatibility/compatibility.html.

Compatibility considerations are provided in the following categories:

JMX 1.2 Implementation

In 9.0, WebLogic Server uses the Java Management Extensions (JMX) 1.2 implementation that is included in JDK 5.0. Prior to this release, WebLogic Server used its own JMX implementation based on the JMX 1.0 specification.

The JMX 1.2 reference implementation introduces serialization incompatibilities. As a result of these incompatibilities in the reference implementation, JMX clients created for WebLogic Server 9.0 or later cannot be used with WebLogic Server 8.1 or earlier. However, despite these incompatibilities, JMX clients created for WebLogic Server 8.1 can be used with 9.0 as follows:

If your JMX client accesses only WebLogic Server MBeans and uses only weblogic.management.MBeanHome, it can be run in a WebLogic Server 9.0 instance without being upgraded.
A JMX client in which WebLogic Server 8.1 classes are used can interact with 9.0 JMX agents if all of the following are true:

The client accesses only WebLogic Server MBeans.
The client uses only weblogic.management.MBeanHome; it does not use the JDK MBeanServer interface.
The WebLogic Server classes are from 8.1 SP4 or 7.0 SP6 with any appropriate patches applied.

If the standard JMX MBeanServer interface is used in your JMX client, either to interact with WebLogic Server MBeans or to create and access custom MBeans, you must include the following JDK startup option for the WebLogic Server 9.0 instance: -Djmx.serial.form=1.0

This startup option causes the JVM to use JMX 1.0 class descriptions when it is serializing objects. The option is required when JMX 1.0 clients communicate with JMX 1.2 agents using the standard JDK classes.

If your JMX client interacts with security provider MBeans, see Security MBeans.

BEA recommends that you update your JMX clients to be compliant with WebLogic Server 9.0. Prior to 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.

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 runtime. 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), BEA 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 at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jmx/understandWLS.html.

Dynamic Configuration Management

Configuration attributes are classified as dynamic or non-dynamic.

Changes to dynamic configuration attributes are available as soon as they are activated, without restarting the affected server or system resource. These changes are made available to the server and runtime hierarchies once they are activated.
Changes to non-dynamic configuration attributes are not immediately available. When a non-dynamic configuration attribute is changed, the server or system resource must be restarted to make the change effective.

WebLogic Server 9.0 introduces 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) will take effect, in current or future batches, until after the server or system resource is restarted. In this case, BEA 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.

To determine whether a change is non-dynamic and requires a restart:

Prior to activating a change you can:

View the change listed in the Change Center in the Administration Console, as described in "Dynamic and Non-Dynamic Changes" in "Using the Change Center" in "Overview of the Administration Console" in Introduction to WebLogic Server and WebLogic Express at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/intro/console.html.
Use the following WLST commands: isRestartRequired or showChanges. For more information, see "WLST Command and Variable Reference" in WebLogic Scripting Tool at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/config_scripting/reference.html.

Once you activate a change you can:

Review the server log to identify whether the change is categorized as non-dynamic.
Check the value of the RestartRequired or PendingRestartSystemResources attribute that is associated with the changed object, if applicable.

To determine which security attributes are dynamic or non-dynamic, see "Security Configuration MBeans" in Securing WebLogic Server at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/secmanage/mbeans.html.

For more information, see "Managing Configuration Changes" in Understanding Domain Configuration at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/domain_config/changes.html.

Modular Configuration and Deployment of JDBC Resources

In 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 tx 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, see "Simplified JDBC Resource Configuration" in Configuring and Managing WebLogic JDBC at http://e-doc.bea.com/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 9.0, as described in the following sections.

Note: Each upgraded JDBC module contains an internal properties section. WebLogic Server uses internal properties to manage the data sources for backward compatibility. Also, some legacy attributes are preserved as properties in the Properties attribute of the JDBC data source file. Do not manually edit any internal properties.

For information about deprecated JDBC features, methods, interfaces, and MBeans, see "Deprecated JDBC Features, Methods, Interfaces, and MBeans" in WebLogic Server and WebLogic Express Release Notes 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 tx 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 (tx or non-tx) and the type of driver used in the related connection pool, as noted in the following table.

Table A-1 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	`EmulateTwoPhaseCommit`¹
Data Source	Non-XA	N/A	None

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 WebLogic JDBC at
http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jdbc_admin/jdbc_datasources.html#llr.

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 and/or failover between data sources.

Data Source Factories

Data source factories are deprecated in this release and are included for backward compatibility only. No conversion of data source factories is required.

JDBC Debugging Enhancements

The JDBC subsystem uses the new system-wide WebLogic Diagnostic Service for centralized debugging access and logging.

See Understanding the WebLogic Diagnostic Framework.

Modular Configuration and Deployment of JMS Resources

JMS configurations in WebLogic Server 9.0 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 migrate your application and the JMS configuration from one environment to another. For example, you can migrate 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 re-configuration.

For more information, see:

"New and Changed JMS Features in This Release" in Configuring and Managing WebLogic JMS at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jms_admin/intro.html#WhatsNewJMS.
"Understanding JMS Resource Configuration" in Configuring and Managing WebLogic JMS at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jms_admin/overview.html.
"Deploying JDBC and JMS Application Modules" in Deploying Applications to WebLogic Server at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/deployment/deploy.html#deploy_resources.

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 WebLogic JMS at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jms_admin/overview.html#jms_interop_modules.

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 will 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 WebLogic Server MBean Reference at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/wlsmbeanref/mbeans/JMSServerMBean.html#AllowsPersistentDowngrade.

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 in WebLogic Server 9.0, and they will be ignored. In WebLogic Server 9.0, this functionality is replaced by uniform distributed destinations. For more information, see "Creating Uniform Distributed Destinations" in "Configuring Distributed Destinations" in Configuring and Managing WebLogic JMS at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jms_admin/advance_config.html#jms_distributed_destination_create.
The AllowCloseInOnMessage attribute for JMS Connection Factories is enabled by default. For more information, see ClientParamsBean in WebLogic Server MBean Reference at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/wlsmbeanref/mbeans/ClientParamsBean.html.
The getExpirationLoggingPolicy attribute in the DeliveryFailureParamsBean has been deprecated. BEA recommends that you update your applications to use the Message Life Cycle Logging feature described in "Message Life Cycle Logging" in Configuring and Managing WebLogic JMS at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jms_admin/troubleshoot.html#message_life_cycle_logging. 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

In WebLogic Server 9.0, the format of the JMS message ID has changed. BEA will continue 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.

Thread Management in JMS Messaging Bridge

The WebLogic Messaging Bridge is fully compliant with WebLogic Server 9.0. For more information about the JMS messaging bridge, see Configuring and Managing the WebLogic Messaging Bridge at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/bridge/index.html.

BEA recommends that you configure a work manager to manage threads, as the WebLogic Server 8.1 mechanism has been deprecated with WebLogic Server 9.0. By default, a common thread pool is used that enables server instances to autotune the thread pool size to maximize throughput. For more information, see "Changing the Thread Pool Size" in Configuring and Managing the WebLogic Messaging Bridge at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/bridge/tuning.html#thread_pool.

JTA Transaction Log Migration

All JTA domain configuration options are persisted from the legacy configuration file. The only changes are at the server level. In 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 machine, 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:

When an explicit upgrade is performed (see Upgrading a Domain), transaction recovery does not run during the upgrade process, but it starts running when you start the server(s).
When an implicit upgrade is performed (see Upgrading a Domain at Administration Server Startup (Implicit Mode)), transaction recovery runs during the server boot process.

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 will 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 WebLogic JTA at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jta/trxcon.html#interop.

Security

The following sections identify changes to security in WebLogic Server 9.0.

Security MBeans

The following table lists the changes to security MBeans in WebLogic Server 9.0.

Table A-2 Changes to Security MBeans in 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 runtime hierarchy following a server reboot. In WebLogic Server 9.0, whether a security MBean attribute change is effective and available to the configuration, management, and runtime 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 `wlconfig` and `weblogic.Admin` tools and pre-9.0 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 will 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 will 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." />`

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 runtime hierarchy following a server reboot.

In WebLogic Server 9.0, whether a security MBean attribute change is effective and available to the configuration, management, and runtime 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 wlconfig and weblogic.Admin tools and pre-9.0 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 will 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 will 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 will encrypt the information the next time it writes to the file.

In 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 "Using the WebLogic Server Java Utilities" in WebLogic Server Command Reference at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/admin_ref/utils.html.

Security for HTTP Requests

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

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 at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/lockdown/practices.html.

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

Web Services

WebLogic Server 8.1 Web Services can be run in 9.0, although the 8.1 Web Services run-time engine has been deprecated in 9.0.

The WebLogic Server 6.1 or 7.0 Web Services need to be upgraded to 8.1 in order to run in 9.0. For more information, see "Upgrading WebLogic Web Services" in Programming WebLogic Web Services at http://download.oracle.com/docs/cd/E13222_01/wls/docs81/webserv/migrate.html.

BEA strongly recommends that you upgrade, to 9.0, all of your 8.1 Web Services, including any 6.1 and 7.0 Web Services that have been upgraded to 8.1. For information about upgrading your existing 8.1 Web Services, see "Upgrading an 8.1 Web Service to 9.0" in Programming Web Services for WebLogic Server at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/webserv/upgrade.html.

Web Applications, JSPs, and Servlets

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

Support for JSP 2.0

WebLogic Server 9.0 implements JSP 2.0. For specific details, see "Web Applications, JSPs, and Servlets" in "What's New in WebLogic Server 9.0" in WebLogic Server and WebLogic Express Release Notes at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/notes/new.html.

Please note the following changes to the JSP behavior:

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 backwards compatibility flags upgrade option during the domain upgrade, as described in Select Upgrade Options, 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>

Deprecated and Obsolete Web Application Features

For a list of Web application features that are deprecated or are not supported by WebLogic Server 9.0, see "Deprecated and Obsolete Web Application Features" in WebLogic Server and WebLogic Express Release Notes at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/notes/new.html#deprecated_and_obsolete_web_application_features.

XML Implementation

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

The default XML parser is the XML parser shipped with the Sun Java 2 JDK 5.0. The previous default XML parser, the Apache Xerces parser (weblogic.apache.xerces.*), is deprecated in 9.0.

You can modify the XML parser that is used by default using the Administration Console. For information about configuring the XML parser, see "Difference In Default Parsers Between Versions 8.1 and 9.0 of WebLogic Server" in Programming WebLogic XML at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/xml/overview.html#deprecated_xerces.

WebLogic Server 9.0 supports Streaming API for XML (StAX), a standard specification from the Java Community Process that provides an easy and intuitive means of parsing and generating XML documents. StAX gives you more control over XML parsing than the WebLogic XML Streaming API, which is deprecated in 9.0. For information about using StAX, see "Using the Streaming API for XML (StAX)" in Programming WebLogic XML at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/xml/stax.html.
You can no longer parse XML documents from within a servlet using the setAttribute and getAttribute methods without some preliminary setup. Specifically, in 9.0, you must configure a WebLogic Server servlet filter called weblogic.servlet.XMLParsingHelper (deployed, by default, on all WebLogic Server instances) as part of your Web application. For more information, see "Parsing XML Documents in a Servlet" in Programming WebLogic XML at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/xml/programming.html#apps005.

XMLBeans and XQuery Implementation

The XMLBean implementation in WebLogic Server 9.0 has been moved from an internal BEA 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:

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

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

The XMLQuery (XQuery) implementation in WebLogic Server 9.0 conforms to the following specifications:

XQuery 1.0 and XPath 2.0 Data Model—W3C Working Draft 23 July 2004 available from the W3C Web site at http://www.w3.org/TR/2004/WD-xpath-datamodel-20040723.
XQuery 1.0: An XML Query Language—W3C Working Draft 23 July 2004 available from the W3C Web site at http://www.w3.org/TR/2004/WD-xquery-20040723.

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 the following URL: http://www.w3.org/TR/2002/WD-xquery-operators-20020816.

In most cases, simple XQuery and XPath operations in pre-9.0 code can be used without change in 9.0. However, you should check your pre-9.0 scripts to identify any changes that may be required with the syntax and/or semantics of your code. For example, you may need to update the XQuery strings that are passed to the XMLObject.selectPath() and XMLObject.execQuery() methods.

Note: In 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. In 9.1, cursors move with fragments.

WebLogic Administration and Configuration Scripts

Due to changes with the MBean hierarchy, BEA does not guarantee that existing configuration and administration scripts (such as WLST, wlconfig, weblogic.Admin, Ant, and so on) will run in 9.0. BEA recommends that you update your scripts to take advantage of the new features provided with WebLogic Server 9.0. For more information about new features and changes in the MBean hierarchy, see "What's New in WebLogic Server 9.0" in the WebLogic Server and WebLogic Express Release Notes at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/notes/new.html.

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

Deprecated Deployment Features

For a list of application deployment features that are deprecated or no longer supported in WebLogic Server 9.0, see "Deprecated and Unsupported Deployment Features" in WebLogic Server and WebLogic Express Release Notes at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/notes/new.html#deprecated_and_unsupported_deployment_features.

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:

Deployment descriptor validation is more strict with the 9.0 release of the EJBGen and ejbc tools. For example, an error is returned if a cmr-field is defined in @ejbgen:relation, but there are no methods tagged with @ejbgen:cmr-field in the Bean class.

Note: ejbc is deprecated in WebLogic Server 9.0; you should use appc instead. For more information, see "appc Reference" in Programming WebLogic Enterprise JavaBeans at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/ejb/appc_ejbc.html.

In pre-9.0 versions of WebLogic Server, applications that define multiple modules, as illustrated in the following excerpt from a configuration file, are deployed successfully regardless of whether a META-INF\application.xml deployment descriptor is defined as part of the application:

<Application Deployed="true" Name="SessionBeanLifeCycleBean"
Path="C:\bea\weblogic70\tools\deployment\ejb" TwoPhase="false">
	<EJBComponent Name="CMFinderTestBean" Targets="myserver" URI="CMFinderTestBean.jar"/>
	<EJBComponent Name="SessionBeanLifeCycleBean" Targets="myserver" 
URI="SessionBeanLifeCycleBean.jar"/>
</Application>

In 9.0, the META-INF\application.xml deployment descriptor is required if a deployed application defines multiple modules. If this type of deployment descriptor is not provided, the upgrade fails with an error similar to the following: [J2EE Deployment SPI:260089]Unable to determine type of application at path 'C:\bea\weblogic70\tools\deployment\ejb' and upgrade will not succeed.
When upgrading a domain, make sure that the deployed applications adhere to the proper J2EE application format. For example, if required by the application, make sure that the applications define the META-INF\application.xml and/or META-INF\weblogic-application.xml deployment descriptors.
For more information about the deployment descriptors, see "Enterprise Application Deployment Descriptor Elements" in Developing Applications with WebLogic Server at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/programming/app_xml.html.

So that your applications can take advantage of the features in the current J2EE specification and release of WebLogic Server, BEA recommends that you upgrade deployment descriptors when you migrate applications to a new release of WebLogic Server. For more information, see "Upgrading Deployment Descriptors From Previous Releases of J2EE and WebLogic Server" in Developing Applications with WebLogic Server at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/programming/overview.html#ddconverter.

Deprecated Startup and Shutdown Classes

Application-scoped startup and shutdown classes are deprecated in WebLogic Server 9.0, in favor of applications that respond to application lifecycle events. BEA recommends that you update your application environment to use the new 9.0 lifecycle events in place of application-scoped and domain-level startup and shutdown classes. For more information, see "Programming Application Lifecycle Events" in Developing Applications with WebLogic Server at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/programming/lifecycle.html.

Administration Console Extension Architecture

The WebLogic Server Administration Console has been completely re-designed in the current release. The Administration Console is now built on the WebLogic Portal Framework, which makes it more open and more readily extensible.

The new architecture necessitates new procedures for extending the Administration Console. WebLogic Administration Console extensions built for prior releases of WebLogic Server will not function with the new Console infrastructure.

For more information about extending the Administration Console, see Extending the Administration Console at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/console_ext/index.html.

Resource Adapters

The following table lists the configuration settings for resource adapters that are deprecated or no longer supported. For more information about new features and changes, see "New and Changed Features in This Release" in Programming WebLogic Resource Adapters at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/resadapter/intro.html#features.

Table A-3 Deprecated or Unsupported Resource Adapter Configuration Settings

This element ...	In WebLogic Server 9.0 ...
Link-Ref Mechanism	This element has been deprecated and replaced by the new J2EE libraries feature. For more information about J2EE libraries, see "Creating Shared J2EE Libraries and Optional Packages" in Developing Applications with WebLogic Server at `http://download.oracle.com/docs/cd/E13222_01/wls/docs90/programming/libraries.html`. 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 WebLogic Resource Adapters at `http://download.oracle.com/docs/cd/E13222_01/wls/docs90/resadapter/creating.html#weblogic-ra-xml`.
`<shrink-period-minutes>`	This element has been deprecated and replaced by `<shrink-frequency-seconds>`, which allows you 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 allows you 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 migrate applications to the WebLogic Tuxedo Connector, as described in WLEC to WebLogic Tuxedo Connector Migration Guide at http://download.oracle.com/docs/cd/E13222_01/wls/docs90/wlec_migration/index.html.

Backward Compatibility Flags

The following configuration flags 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 backwards compatibility flags option during an upgrade, as described in Upgrading a Domain in Graphical Mode.

Table A-4 Backward Compatibility Flags

Category	Backward Compatibility Flag	For More Information
Security	`EnforceStrictURLPattern`—Specifies whether the server should enforce strict adherance 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. In WebLogic Server 9.0, URL-pattern matching is strictly enforced across operating systems	`SecurityConfigurationMBean` at `http://download.oracle.com/docs/cd/E13222_01/wls/docs90/wlsmbeanref/mbeans/SecurityConfigurationMBean.html`
Web Application	`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. In WebLogic Server 9.0, if you specify the wildcard () character as the role name, all users/roles in the Web application* will have access to the resource collection. `FilterDispatchedRequestsEnabled`—Specifies whether to apply filters to dispatched requests. In 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. In 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. In WebLogic Server 9.0, the JSP Compiler no longer allows run-time expression values.	`WebAppContainerMBean` at `http://download.oracle.com/docs/cd/E13222_01/wls/docs90/wlsmbeanref/mbeans/WebAppContainerMBean.html`

Deprecated and Removed APIs

This section summarizes APIs that have been deprecated or removed from WebLogic Server in 9.0.

Note: If you want to rebuild the WebLogic Server 8.1 MedRec application in the 9.0 environment, you must replace references to the weblogic.webservice.tools.wsdlp package with the new package name, weblogic.webservice.wsdl, in two Java files: medrec/src/common/web/com/bea/medrec/utils/MedRecWebAppUtils.java and medrec/src/clients/com/bea/medrec/webservices/swing/EditProfileFrame.java.

The 8.1 and 9.0 packages, weblogic.webservice.tools.wsdlp and weblogic.webservice.wsdl, respectively, are not publicly available.

Deprecated APIs

For a list of deprecated APIs, see http://download.oracle.com/docs/cd/E13222_01/wls/docs90/javadocs/deprecated-list.html.

Removed APIs

This section describes the APIs that have been removed in WebLogic Server 9.0, including:

Removed APIs, Deprecated in WebLogic Server 8.1

The following table provides a list of APIs that have been removed in WebLogic Server 9.0 and were deprecated in WebLogic Server 8.1.

Table A-5 Removed APIs—Deprecated in WebLogic Server 8.1

Package Name	Interface/Class/Exception	Method/Variable
`weblogic.jdbc.common`	`Oracle`	`*`
`weblogic.jdbc.oci`	`*`	`*`
`weblogic.jdbc.oci.xa`	`*`	`*`
`weblogic.management.configuration`	`JDBCDataSourceMBean`
	`NetworkChannelMBean`
	`SecurityMBean`
`weblogic.management.console`	`extensibility`	`ExtensibleTag`
`weblogic.net.http`	`HttpsURLConnection`	`weblogic.security.SSL.HostnameVerifier getDefaultHostnameVerifier()`
`weblogic.security`	`Key`
`weblogic.security.SSL`	`HostnameVerifier`	`boolean verify(java.lang.String, java.lang.String)` `boolean verify(java.net.InetAddress, weblogic.security.X509)`
`weblogic.security.service`	`WebResource`

Removed APIs, Deprecated in WebLogic Server 7.0

The following table provides a list of APIs that have been removed in WebLogic Server 9.0 and were deprecated in WebLogic Server 7.0.

Table A-6 Removed APIs—Deprecated in WebLogic Server 7.0

Package Name	Interface/Class/Exception	Method/Variable
`weblogic.common`	`T3User`	`T3User(weblogic.security.SSL.SSLCertificate)`
`weblogic.common`	`WLSerializable`
`weblogic.io.common`	`T3File`
	`T3FileInputStream`
	`T3FileOutputStream`
	`T3FileSystem`
`weblogic.management.configuration`	`Acl`
	`BasicRealmMBean`
	`CachingRealmMBean`
	`CustomRealmMBean`
	`FileRealmMBean`
	`Group`
	`LDAPRealmMBean`
	`NTRealmMBean`
	`PasswordPolicyMBean`
	`Principal`
	`RDBMSRealmMBean`
	`RealmException`
	`RealmIterator`
	`RealmMBean`
	`RealmManager`
	`UnixRealmMBean`
	`User`
	`XMLRegistryEntryMBean`
`weblogic.management.runtime`	`DeploymentRuntimeMBean`
`weblogic.security`	`acl`	`CertAuthentication weblogic.security.acl.User authenticate(java.lang.String, weblogic.security.Certificate[], boolean)`
	`acl`	`CertAuthenticator weblogic.security.acl.User authenticate(java.lang.String, weblogic.security.Certificate[], boolean)`
	`acl`	`Security void receiveSecurityMessage(weblogic.rjvm.JVMID, weblogic.security`
	`acl`	`SecurityMessage void execute(weblogic.rjvm.JVMID)`
	`audit`	`Audit void certificateInvalid(java.lang.String, java.lang.Object, weblogic.security.X509)`
	`audit`	`Audit void rootCAInvalid(java.lang.String, java.lang.Object, weblogic.security.X509)`
	`audit`	`AuditProvider void certificateInvalid(java.lang.String, java.lang.Object, weblogic.security.X509)`
	`audit`	`AuditProvider void rootCAInvalid(java.lang.String, java.lang.Object, weblogic.security.X509)`
`weblogic.security`	`AuthenticationException`
	`Certificate`
	`Cipher`
	`Cipher3EDE`
	`CipherCBC`
	`CipherException`
	`Coder`
	`CoderException`
	`CoderInputStream`
	`CoderOutputStream`
	`DES`
	`DiffieHellman`
	`DigestInputStream`
	`DigestOutputStream`
	`DigestSignature`
	`Entity`
	`HexOutputStream`
	`JDK11Certificate`
	`KeyManagementException`
	`MD5RandomBitsSource`
	`NullCipher`
	`NullOutputStream`
	`PKCS5`
`weblogic.security`	`Padding`
	`RC4`
	`RSA`
	`RSAKey`
	`RSAMDSignature`
	`RSAPrivateKey`
	`RSAPrivateKeyPKCS8`
	`RSAPublicKey`
	`RSApkcs1`
	`RandomBitsSource`
	`service`	`InvocableResource java.lang.String toString()`
		`MBeanResource`
		`RealmAdapterAclResource`
	`Signature`
	`SimpleRandomBitsSource`
	`SpinnerRandomBitsSource`
	`StreamCipher`
	`Streamable`
	`SymmetricCipher`
	`TeeOutputStream`
	`X500Name`
	`X509`
`weblogic.security.SSL`	`BadMACException`
	`Biguint`
	`CipherSpec`
	`RecordInputStream`
	`SSLCertificate`
	`SSLParams`
	`SSLSocket`
	`SessionParams`
	`TrustManager boolean certificateCallback(weblogic.security.X509[], int)`
`weblogic.xml.sax`	`XMLInputSource`

Removed APIs (Not Deprecated)

The following provides a list of APIs that have been removed in WebLogic Server 9.0, without being deprecated. The majority of these APIs have been removed because of changes to the applicable standard, or because the APIs were applicable for WebLogic Server internal use and not for external application use.

Note: In the following table, * (asterisk) represents a wildcard character.

Table A-7 Removed APIs (Not Deprecated)

Package Name	Interface/Class/Exception	Method/Variable
`weblogic.apache`	`*`	`*`
`weblogic.common`	`CallbackDispatcher`	`CallbackDispatcher(weblogic.common.ClientCallback, boolean)`
`weblogic.common`	`T3ResourceDef T3ResourceFactory`	`*`
`weblogic.jdbc.pool`		`CallableStatement. Connection. DatabaseMetaData. PreparedStatement. ResultSet. ResultSetMetaData. Statement.`
`weblogic.jms`		`VirtualDestination.`
`weblogic.jms.extensions`	`JMSHelper`	`getRepositoryForDomain.`
`weblogic.jndi`	`Environment`	`getProviderRJVM. getSecuritySubject. getUseIIOPServiceProvider. setProviderRJVM. setSecuritySubject. setUseIIOPServiceProvider.`
`weblogic.jndi`	`WLContext`	`PROVIDER_RJVM. USE_IIOP_SERVICE_PROVIDER.`
`weblogic.logging`	`ConsoleHandler`	`isLoggable.`
	`FileStreamHandler`	`isLoggable.`
	`WLLevel`	`WLLevel.`
	`WLLogRecord`	`setId. setMachineName. setServerName. setThreadName. setTransactionId. setUserId.`
`weblogic.management`		`WebServiceLegalHelper.`
	`AdminServerAdmin`	`*`
	`DeploymentException`	`getApplication()`
	`DistributedManagementException`	`MAX_EXCEPTIONS`
	`LocalAdminServer`	`*`
	`ManagedServerAdmin`	`*`
	`RemoteMBeanServer`	`java.lang.String getSharedCommoMBeanRepositoryIdentifier(javax.management.ObjectName) java.util.List getCommoMBeans(javax.management.ObjectName)`
	`tools`	`*`
	`WebLogicObjectName`	`WebLogicObjectName(java.lang.String, java.lang.String)`
	`UndeploymentException`	`getApplication()`
	`utils`	`InvalidPasswordException InvalidPredicateException`
`weblogic.management.configuration`	`*`	`*`
`weblogic.management.runtime`	`*`	`*`
`weblogic.management.security`	`BaseMBeanImpl`	`getRequiredModelMBean.`
	`ProviderMBean`	`setRealm`
	`RealmMBean`	`setAdjudicator setUserLockoutManager`
`weblogic.management.security.authentication`	`UserLockoutManagerMBean`	`setRealm`
`weblogic.management.timer`	`Timer`	`void addNotification(weblogic.time.common.internal.TimerNotification) java.lang.String getDispatchPolicy() void removeNotification(weblogic.time.common.internal.TimerNotification) void removeNotification(weblogic.time.common.internal.TimerNotification, boolean) void run() void setDispatchPolicy(java.lang.String) void start(java.lang.ThreadGroup,java.lang.String,int)`
`weblogic.net.http`	`HttpClient`
	`HttpsClient`
	`HttpUnauthorizedException`
	`HttpURLConnection`	`*`
	`HttpsURLConnection`	`*`
	`KeepAliveCache`
	`KeepAliveStream`
	`MessageHeader`
`weblogic.rmi`	`Naming`	`void bind(java.lang.String, weblogic.rmi.Remote) weblogic.rmi.Remote lookup(java.lang.String) void rebind(java.lang.String, weblogic.rmi.Remote)`
`weblogic.security`	`HMAC`	`*`
`weblogic.security`	`Key`	`*`
`weblogic.security.providers.authentication`	`*`	`*`
`weblogic.security.providers.authorization`	`*`	`*`
`weblogic.security.service`	`Auditor`	`*`
	`SecurityManager`	`*`
	`WebResource`	`*`
	`WebServiceResource`	`void initialize(java.lang.String) void main(java.lang.String[]) WebServiceResource WebServiceResource(weblogic.security.service.WebResource, java.lang.String, java.lang.String[], java.lang.String[])`
`weblogic.security.spi`	`KeyStoreProvider`
`weblogic.security.SSL`	`HostnameVerification`
	`HostnameVerifier`	`verify(java.lang.String, java.lang.String) verify(java.net.InetAddress, weblogic.security.X509)`
	`SSLClientInfo`
	`SSLSocketFactory`	`*SSLSocketFactory()`
`weblogic.servlet.proxy`	`GenericProxyServlet`
	`GenericProxyServlet`	`ProxyConnection ProxyConnectionPool`
	`HttpClusterServlet`	`RequestInfo Server ServerList`
	`HttpProxyServlet`
`weblogic.webservice.async`	`KernelFeederImpl`	`ExecuteTask void execute(weblogic.kernel.ExecuteThread)`
`weblogic.webservice.client`	`BaseWLSSLAdapter`	`void main(java.lang.String) void _setStrictChecking(boolean)`
	`JSSEAdapter`	`javax.net.ssl.SSLSocketFactory getSocketFactory() void setSocketFactory(javax.net.ssl.SSLSocketFactory)`
	`SSLAdapterFactory`	`void main(java.lang.String)`
`weblogic.xml`	`xpath`	`XMLNodeXPath.`
`weblogic.xml.security.specs`	`SecuritySpec`	`java.lang.String getName()`
`weblogic.xml.security.wsse`	`SecurityElementFactory`	`weblogic.xml.security.wsse.Token createToken(java.lang.String, java.lang.String, javax.xml.namespace.QName)`
`weblogic.xml.security.wsse`	`UsernameToken`	`String getPasswordType()`