|
|
This section describes important compatibility information that you should consider before upgrading to WebLogic Server 10.3.
Also see Compatibility Statement for Oracle WebLogic Server 10g Release 3 (10.3).
Compatibility considerations are provided in the following categories:
As of WebLogic Server 9.0, WebLogic Server uses the Java Management Extensions (JMX) 1.2 implementation that is included in JDK 5.0. Prior to 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 10.3 as follows:
weblogic.management.MBeanHome, it can be run in a WebLogic Server 9.2, 10.0, or 10.3 instance without being upgraded. -Djmx.serial.form=1.0This 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.
Oracle recommends that you update your JMX clients to be compliant with WebLogic Server 10.3. 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), 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.
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) will 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:
isRestartRequired or showChanges. For more information, see
“WLST Command and Variable Reference” in WebLogic Scripting Tool.To determine which security attributes are dynamic or non-dynamic, see “Security Configuration MBeans” in Securing WebLogic Server.
For more information, see “Managing Configuration Changes” in Understanding Domain Configuration.
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 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 introduced in WebLogic Server 9.0, see “Simplified JDBC Resource Configuration” in Configuring and Managing WebLogic JDBC.
The WebLogic Upgrade Wizard automatically converts JDBC data sources, connection pools, MultiPools, and data source factories to their new counterparts in WebLogic Server 10.3, 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 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.
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:
| 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 Table B-1.
1Depending on your environment, you may want to consider using the |
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 are deprecated as of WebLogic Server 9.0 and are included for backward compatibility only. No conversion of data source factories is required.
The following sections describe changes to JDBC support:
As of 10.3, WebLogic Server is compliant with the JDBC 4.0 specification, with the enhancements and exceptions described in “JDBC 4.0 Support” in the Release Notes.
The WebLogic Type 4 JDBC driver for Oracle has been deprecated in WebLogic Server 10.3. It will be removed in the next release of WebLogic Server. Instead of this deprecated driver, you should use the Oracle Thin Driver that is also provided with WebLogic Server. For details about the Oracle Thin Driver, see “Using Third-Party JDBC Drivers with WebLogic Server” in Configuring and Managing WebLogic JDBC.
The WebLogic Type 4 JDBC drivers included with WebLogic Server are provided from DataDirect. As of 10.3, the drivers have been updated to DataDirect Version 3.7. For information about changes to these drivers, including to support JDBC 4.0, see “Updated WebLogic Type 4 JDBC Drivers” in the Release Notes.
WebLogic Server 10.3 includes support for Oracle 11g and 11g RAC (Real Application Clusters).
See “Using WebLogic Server with Oracle RAC” in Configuring and Managing WebLogic JDBC.
The JDBC subsystem uses the new system-wide WebLogic Diagnostic Service for centralized debugging access and logging.
See Using the WebLogic Diagnostic Framework Console Extension.
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 re-configuration.
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.
Please note the following JMS configuration changes:
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.
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.
AllowCloseInOnMessage attribute for JMS Connection Factories is enabled by default. For more information, see
ClientParamsBean in WebLogic Server MBean Reference.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 WebLogic JMS. 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.
As of WebLogic Server 9.0, the format of the JMS message ID has changed. Oracle 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.
The message paging feature for freeing up virtual memory during peak message load situations is always enabled on JMS servers. Additionally, administrators no longer need to create a dedicated message paging store since 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 WebLogic Server Performance and Tuning.
Oracle recommends using Work Manager concepts to manage threads, as 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 Server domain or specifically to an application component. For more information, see “Using Work Managers to Optimize Scheduled Work” in Configuring Server Environments.
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.
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 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.
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.
The following sections identify changes to security.
The Windows NT Authentication provider is deprecated as of WebLogic Server 10.0. Use one or more of the other supported Authentication providers instead.
As of 9.2, 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 10.3 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 10.3 will 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 wish, 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 the Security for Oracle WebLogic Server 10g Release 3 page.
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. |
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:
For SAML 2.0 Web SSO, 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.
WebLogic Server 10.3 Web Services now supports SAML Token Profile 1.1. This feature includes support for SAML 2.0 and SAML 1.1 assertions, and is backwards 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 “WLS 9.2 Security Policy” supports SAML Token Profile 1.0/SAML 1.1 only. |
WebLogic Server 10.3 provides the option of using an external RDBMS as a datastore that is used by the following security providers:
This datastore, 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 datastore, 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. Prior to booting the domain, you create the tables in the datastore 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 WebLogic Server.
WebLogic Server 10.3 includes a Password Validation provider, which can be configured with one of the following authentication providers to enforce a set of configurable password composition rules:
When a password is created or modified using an authentication provider that has been configured with the Password Validation provider, the password is automatically validated against a set of composition rules. The password composition rules are configurable and can govern the minimum length of passwords, minimum number of alphabetic or numeric characters that are required, the number of non-alphanumeric characters that are required, and more.
Table B-2 lists the changes to security MBeans as of WebLogic Server 9.0.
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.
As of 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.
|
|
|
|
|
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.
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 “Using the WebLogic Server Java Utilities” in Oracle WebLogic Server Command Reference.
By default, when an instance of WebLogic Server 10.3 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 prior to 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.
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
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 Securing WebLogic 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.
WebLogic Server 8.1 Web Services can be run in 10.3, although the 8.1 Web Services run-time engine has been deprecated as of 9.0.
No web service upgrade is required going from 9.2 to 10.0, or from 10.0 to 10.3.
The WebLogic Server 7.0 Web Services need to be upgraded to at least 8.1 in order to run in 10.3. For more information, see “Upgrading WebLogic Web Services” in Programming WebLogic Web Services.
Oracle strongly recommends that you upgrade, to 10.3, all of your 8.1 Web Services, including any 7.0 Web Services that have been upgraded to 8.1:
For information about upgrading your existing 8.1 Web Services to 10.3, see “Upgrading WebLogic Web Services From Previous Releases to 10g Release 3” in Getting Started With WebLogic Web Services Using JAX-RPC.
| Note: | See also Message-Level Security in Web Services. |
The following sections provide important compatibility information for Web applications, JSPs, and Servlets in WebLogic Server 10.3:
For a list of Web application features that are deprecated or are not supported as of WebLogic Server 10.3, see “Deprecated Functionality” in the Release Notes.
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 or not 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 WebLogic Security for complete information.
For WebLogic Server 10.3, backward compatibility for WebLogic Server 9.2 or earlier is supported via 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 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.3 also supports JSP 2.0.
See Backwards 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.
JSP 2.0 was supported as of WebLogic Server 9.0, and continues to be supported as described in Backwards Compatibility Flags. Please note the following changes to the JSP behavior as required in support of JSP 2.0:
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:<%@ page import="com.foo.bar.*" %>
<%@ page import="com.foo.xyz.*" %>
...
\r\n is output for each page directive.
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:
<%@ page import="com.foo.bar.*, com.foo.baz.*"
contentType="text/html" pageEncoding="UTF-8" errorPage="Error.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>
As of the Servlet 2.3 Specification from Sun Microsystems, which is downloadable at
http://java.sun.com/products/servlet/download.html#specs, the following syntax is used to define mappings:
/ (forward 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.* (asterisk) specifies an extension mapping.
These changes introduce a change in behavior with the following HttpServletRequest methods:
To better illustrate the change in behavior, consider a request /abc/def.html that resolves to ServletA:
To ensure that the path info returned is non-null, replace all occurrences of the / (forward slash) servlet mapping string with /*.
Please note the following changes to XML support as of WebLogic Server 9.0:
weblogic.apache.xerces.*), is deprecated as of 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.
setAttribute and getAttribute methods without some preliminary setup. Specifically, as of 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.
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:
As of 9.0, the XMLQuery (XQuery) implementation conforms to the following specifications:
http://www.w3.org/TR/2004/WD-xpath-datamodel-20040723.
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
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 will behave the same in 10.0. To ensure that the XQuery and XPath operations produce the expected results, you can review and/or update the existing XMLObject.selectPath() and XMLObject.execQuery() method calls using one of the following methods:
import org.apache.xmlbeans.impl.store.Path;
XmlObject xo = ?
xo.selectPath(".//c",(new XmlOptions()).put(Path._forceXqr12002ForXpathXQuery));
| Note: | The 2002 XQuery engine is deprecated as of WebLogic Server 9.0, and is available for backward compatibility. It is only used if you specify this parameter. Otherwise, the 2004 XQuery engine is used, by default. |
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.
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) will run in 10.3. Oracle recommends that you update your scripts to take advantage of the new features provided as of WebLogic Server 10.3. For more information about new features and changes in the MBean hierarchy, see
“What’s New in WebLogic Server” in the Release Notes.
For additional information about upgrading your application infrastructure and the scripting tools that have been deprecated, see Step 1: Upgrade Your Application Infrastructure.
This section describes changes in the use of deployment descriptors in a WebLogic Server environment, as of release 9.0:
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 as of WebLogic Server 9.0; you should use appc instead. For more information, see
“appc Reference” in Programming WebLogic Enterprise JavaBeans. |
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>
As of 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 Java EE 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.
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 with WebLogic Server.
The following sections describe changes to the Administration Console:
WebLogic Server 10.3 introduces new options that have been added for configuring Console behavior, including the ability to do the following:
For more information, see “What’s New in WebLogic Server” in the Release Notes.
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 Administration Console extensions built for releases of WebLogic Server prior to 9.0 will not function with the new Console infrastructure. For more information about extending the Administration Console, see Extending the Administration Console.
Version 9.2 of WebLogic Server introduced the following changes to console extensions:
<%@ 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 pathname syntax to import Apache Struts, Apache Beehive, or the JSTL tag libraries must update all pathnames 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.
WebLogic Portal requires that any explicit Skeleton URI references be fully qualified relative to the webapp. However, the documentation and some of the 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 will continue to work. However, any console extensions that you have written should be updated to use fully qualified skeleton URIs, as these relative references may no longer function correctly in a future release.
Table B-3 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” in Release Notes.
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 with 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 WebLogic Resource Adapters.
|
|
WLEC was deprecated in WebLogic Server 8.1. WLEC users should move applications to the WebLogic Tuxedo Connector, as described in WLEC to Oracle WebLogic Tuxedo Connector Migration Guide.
The SNMPAgentMBean MBean MibDataRefreshInterval and ServerStatusCheckIntervalFactor attributes were deprecated in WebLogic Server 10.0 and are ignored.
The configuration flags in Table B-4 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.
|
||
|
For information about deprecated and removed APIs, see “Deprecated Functionality” in the Release Notes.
|