| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Server 8.1 Upgrade Guide > Upgrading WebLogic Server 7.0 to Version 8.1 |
|
WebLogic Server 8.1 Upgrade Guide
|
Upgrading WebLogic Server 7.0 to Version 8.1
Upgrading WebLogic Server 7.0 to version 8.1 involves changing your WebLogic Server start command scripts and environment settings. In some cases, it is necessary to move your domain directory.
For example procedures to upgrade applications from earlier versions of WebLogic Server to WebLogic Server 8.1, see Upgrading Example Applications to WebLogic Server 8.1.
For answers to specific questions on upgrading to WebLogic Platform 8.1, see the Upgrading section of the WebLogic Server FAQs.
The following sections of this document contain information for upgrading your system from WebLogic Server 7.0 to WebLogic Server 8.1:
Upgrading Your WebLogic Server Configuration: Main Steps
Take the following steps to upgrade from WebLogic Server 7.0 to WebLogic Server 8.1:
To upgrade a cluster of servers, follow the above steps for each server and then follow the steps outlined in Setting Up WebLogic Clusters in Using WebLogic Server Clusters. In cases where you invoke an application by using RMI/T3 or RMI/IIOP, WebLogic Server 6.1, 7.0, and 8.1 are interoperable. Within a domain, however, all servers must be of the same version.
For information on upgrading WebLogic Server license files, see Upgrading Licenses from WebLogic Server 7.0 in the Installation Guide.
If you used WebLogic Server startup scripts with a previous version of the product, modify them to work with WebLogic Server 8.1.
For other examples of modifying the startup scripts, see Upgrading Example Applications to WebLogic Server 8.1.
call "WL_HOME\server\bin\startWLS.cmd"
You may need to modify other settings in your startup script. Some possibilibities are described below.
WebLogic Server 8.1 installs the JVM, JDK 1.4.1, with the server installation. The setenv.sh scripts provided with the server all point to the JVM. The latest information regarding certified JVMs is available at the Certifications Page.
Understanding the WebLogic Server 8.1 Directory Structure
The directory structure in WebLogic Server 8.1 is different from that of 7.0. For complete information on the updated directory structure see Understanding the WebLogic Server Directory Structure in Performing Post-Installation Tasks in the Installation Guide.
If you are booting your WebLogic Server 7.0 domain with the WebLogic Server 8.1 environment, the new directory structure is created automatically. However, if you have custom tools or scripts that rely on the WebLogic Server 7.0 domain directory structure, you need to update those tools relative to the new directory structure. Similarly, if you have a scripted tool for creating domains in the WebLogic Server 7.0 environment, you will have to change those scripts. It is best to use the Configuration Wizard, which can be scripted.
Upgrading an Application from WebLogic Server 7.0 to WebLogic Server 8.1
The following steps upgrade an application from WebLogic Server 7.0 to WebLogic Server 8.1:
This section describes these steps in detail.
Each 7.0 and 8.1 domain must have its own directory, because it is not possible to have multiple config.xml files in the same directory.
If your 7.0 /config/domain directory is not located in the WebLogic Server 7.0 installation, you can re-use your WebLogic 7.0 location for WebLogic Server 8.1.
Tip: You can delete any directories that begin with a dot ("."), which are files or directories that WebLogic Server has created for its own use.
WebLogic Server configurations rely on a number of files that may be stored on the file system. Typically, these files are persistence repositories (log files, file-based repositories, etc.) or utilities (Java compiler). These files can be configured using fully qualified or relative paths.
If all external files are defined using relative paths and are located in or below the domain directory, skip the remainder of this step.
For external files that are defined using relative paths that are located outside the domain directory, re-create the directory structure relative to the new config directory and copy the associated files into the new directories. For external files that are defined using fully qualified paths, determine whether it is appropriate to re-use these files in the WebLogic Server 8.1 deployment.
For example, log files and persistence stores can be re-used; however, you may want to update utilities such as the Java compiler to use the latest version. For files that should be updated, use the WebLogic Server 8.1 Administration Console to configure the appropriate attribute to use the new file or utility before proceeding to the next step.
Note: WebLogic Server 8.1 will not deploy applications that have deployment descriptor errors.
Additional Upgrade Procedures and Information
This section contains upgrade information about the following topics:
The built-in transformer in WebLogic Server 8.1 is based on the Apache Xalan 2.2 transformer.
Use of the Xalan APIs directly has been deprecated. If you are still using those APIs and encounter difficulties, you should use the Java API for XML Processing (JAXP) to use XSLT.
Changes were made to Apache's Xalan code to enable Xerces and Xalan to work together. You may encounter problems if you use Xalan from Apache, because it will not include these changes.
In general, it is best to use JAXP and to port any vendor-specific code to a neutral API such as JAXP for SAX, DOM, and XSL processing.
Previous versions of WebLogic Server included the unmodified versions of the Xerces parser and Xalan transformer from www.apache.org in the WL_HOME\server\ext\xmlx.zip file. The ZIP file no longer includes these classes and interfaces. Download the unmodified Xerces parser and Xalan transformer directly from the Apache Web site.
The Xerces XML parser used in Weblogic Server 8.1 is stricter than the one used in WebLogic Server 7.0, and may refuse to parse erroneous XML that was accepted by the WebLogic Server 7.0 parser.
The built-in XML parser for WebLogic Server 8.1 is based on the Apache Xerces 1.4.4 parser. The parser implements version 2 of the SAX and DOM interfaces. Users who used older parsers that were shipped in previous versions may receive deprecation messages.
WebLogic Server 8.1 also includes the WebLogic FastParser, a high-performance XML parser specifically designed for processing small to medium size documents, such as SOAP and WSDL files associated with WebLogic Web services. Configure WebLogic Server to use FastParser if your application handles mostly small to medium size (up to 10,000 elements) XML documents. For more information, see Administering WebLogic Server XML.
Previous versions of WebLogic Server included the unmodified versions of the Xerces parser and Xalan transformer from www.apache.org in the WL_HOME\server\ext\xmlx.zip file. The ZIP file no longer includes these classes and interfaces. Download the unmodified Xerces parser and Xalan transformer directly from the Apache Web site.
To see the explicit differences between the old and new parsers, use a tool contained in the apichange.zip file located on dev2dev Online.
When upgrading Web Services from WebLogic Server 7.0 to WebLogic Server 8.1, you will need to re-run servicegen to regenerate the webservice deployment units.
For detailed information on upgrading a 7.0 WebLogic Web service to 8.1, see Upgrading 7.0 WebLogic Web Services to 8.1.
For examples of using JAX-RPC to invoke WebLogic Web services, see Invoking Web Services.
For general information on the differences between 7.0 and 8.1 Web services, see Overview of WebLogic Web Services.
To see a complete listing of the specification changes, you can view and download the EJB 2.0 final specification at http://java.sun.com/products/ejb/2.0.html.
Run DDConverter Before Using New Features
Before using any features new in this release, be sure to run the DDConverter tool to convert existing EJB deployment descriptors to 8.1 descriptors. For more information, see the discussion of the DDConverter tool.
New Default Values for EJB Deployment Descriptor Elements
As of this release, there are new default values for the following EJB deployment descriptor elements:
|
The default value is False for beans that use optimistic concurrency. The default value is True for beans that use other concurrency types, such as database. |
||
Note: The new default values are only in effect when using the 8.1 version of the deployment descriptors. Existing beans that use pre-8.1 versions of the deployment descriptors can be deployed on the 8.1 release with no change in behavior.
For more information on EJB deployment descriptors, see The weblogic-ejb-jar.xml Deployment Descriptor and The weblogic-cmp-rdbms-jar.xml Deployment Descriptor.
Inserting a New CMP Bean at Commit Time
In WebLogic Server 7.0, to have the EJB container perform bulk inserts, you set the weblogic-cmp-rdbms-jar.xml element delay-database-insert-until to commit.
As of the current release, the commit value is no longer supported for delay-database-until-insert. To permit bulk inserts, set the new weblogic-cmp-rdbms-jar.xml element enable-batch-operations to true.
enable-batch-operations takes effect on the jar level, so you need only set this tag once per jar. By contrast, delay-database-insert-until had to be set for every bean.
For more information on entity batch operations see Entity Batch Operations.
New weblogic-ra-xml Deployment Descriptor Elements
If the resource adapter does not support this method (i.e. always return null for this method) then WebLogic Server will bypass this method call during a connection request.
WebLogic Server 6.1 and 7.0 provided a Deployment Descriptor Editor in the Administration Console. This editor provided the capability to view the current ra.xml and weblogic-ra.xml deployment descriptor elements for resource adapters. Descriptor elements could also be modified through this editor and persisted to the descriptor files within the resource adapter. However, the new element values did not take effect dynamically at runtime. The resource adapter needed to be redeployed for the new descriptor elements to take effect.
WebLogic Server 8.1 deprecated the Deployment Descriptor Editor in the Administration Console and replaced it with a Descriptor tab. In this tab, descriptor elements can be viewed, modified and persisted to the descriptor file within the resource adapter in the same manner that they were using the Deployment Descriptor Editor. However, these descriptor elements take place dynamically at runtime without requiring the resource adapter to be redeployed. The descriptor elements contained in the Descriptor tab are limited to only those descriptor elements that may be dynamically changed at runtime. These include the following weblogic-ra.xml elements:
Last-resource Commit Optimization
Normally, if a client wants operations on multiple resource adapter connections to participate in a global / XA transaction then the resource adapters involved are required to support XATransaction. However, resource adapters that only support Local Transactions may also be involved in a global / XA transaction, but in a limited manner, since they do not receive 2-phase commit messages from the transaction manager.
In WebLogic Server 8.1, if the server detects a Local Transaction capable resource adapter connection in a global transaction, the transaction manager first issues prepare messages to the XAResources involved in the transaction. Then, after all XAResources have prepared successfully, the operation on the Local Transaction capable resource adapter is performed. If the operation is successful, the global transaction is committed. If the operation fails, then the global transaction is rolled back. This prevents the possibility of the Local Transaction resource adapter's commit failing after a XA resource has already been committed.
Notes: This optimization allows multiple XAResources but not more than one Local Transaction capable resource adapter to participate in a global transaction. Attempts to include more than one Local Transaction capable resource adapter in a global / XA transaction will fail with an exception.
Previous to WebLogic Server 8.1, there was no restriction on the number of Local Transaction capable resource adapters that could be involved in a global / XA transaction. Also, the ordering of the prepares and commits was not coordinated specially for Local Transaction capable resource adapters as it now is in WebLogic Server 8.1. It was previously possible for a call to commit on a Local Transaction capable resource adapter to fail after some of the XA Transaction resource adapters had already been successfully committed. This created the case where some resources would be committed and some rolled back for a global / XA transaction. The optimization resolves this previous issue.
weblogic-ra.xml Deployment Descriptor Changes
The <connection-maxidle-time> has been deprecated. It is replaced by inactive-connection-timeout-seconds.
The <connection-maxidle-time> element identifies the amount of time (in seconds) a Connection handle can remain idle. This element prevents leaks when an Application may have not closed a connection after completing usage. Idle connections will only be terminated in the case where the connection pool becomes full, and a new connection request is about to fail because of this.
<shrink-period-minutes> has been deprecated. It has been replaced by shrink-frequency-seconds.
The <shrink-period-minutes> element identifies the amount of time the Connection Pool Management will wait between attempts to reclaim unused Managed Connections.
<connection-cleanup-frequency> and connection-duration-time were deprecated in WebLogic Server 7.0. In WebLogic Server 8.1, these elements have no effect if specified. These elements have been replaced by inactive-connection-timeout-seconds.
The connection-cleanup-frequency element identifies the amount of time (in seconds) the Connection Pool Management will wait between attempts to destroy Connection handles which have exceeded their usage duration. This element, used in conjunction with connection-duration-time, prevents connection leaks when an Application may have not closed a connection after completing usage.
The <connection-duration-time> element identifies the amount of time (in seconds) a Connection handle can be active. This element, used in conjunction with connection-cleanup-frequency, prevents leaks when an Application may have not closed a connection after completing usage.
When a connection request is made, WebLogic Server returns to the client (via the resource adapter) a Proxy object that wraps the connection object. WebLogic Server uses this proxy to provide features that assist applications using the WebLogic Server implementation of the J2EE Connector Architecture. These features include (1) connection leak detection capabilities and (2) late XAResource enlistment when a connection request is made before starting a global transaction that uses that connection.
If the connection object returned from a connection request is cast as a Connection class, a ClassCastException can occur. This exception is caused by either (1) the resource adapter doing the cast or (2) the client doing the cast during a connection request.
In WebLogic Server 8.1, an attempt is made to detect the ClassCastException caused by the resource adapter (case (1), above). If the server detects that this cast is failing, it turns off the proxy wrapper feature and proceeds by returning the connection object during a connection request (unwrapped). The server logs a warning message to indicate that the proxy wrapper has been turned off.
Note: When this occurs, connection leak detection and late XAResource enlistment features are also turned off (but currently no indication of this is given in the console monitoring).
Note: The attempt for WebLogic Server to detect the ClassCastException is made by acting as a client using container-managed security. This requires the resource adapter to be deployed with security credentials defined.
If the client is doing the cast and getting a ClassCastException, the customer (client) code can be modified as follows:
Example: The client is casting the connection object to MyConnection
Instead of MyConnection being a class that implements the resource adapter's Connection interface, modify it to be an interface that extends Connection.
Implement a MyConnectionImpl class that implements the MyConnection interface.
Application Container Managed Security Log Messages
Messages indicating whether the client is using application or container managed security are no longer written to server log.
Classloader and Packaging Issues
In WebLogic Server 8.1 each resource adapter will have its own classloader to load its classes in the same manner as Web applications. With this change in affect, components like Web applications and EJBs that are packaged along with a resource adapter in an application archive (.ear file), do not have visibility into the resource adapter's classes. If such visibility is required then the classes of the resource adapter may be placed in APP-INF/classes or jarred and placed in APP-INF/lib of the application archive.
WebLogic Server 8.1 will not deploy an application that has any errors in its deployment descriptor. Previous versions of WebLogic Server would deploy an application that had errors in its deployment descriptor. For example, if your 7.0 application was missing a reference description stanza in the deployment descriptor, the application will not deploy in the 8.1 server until you add that stanza. A typical stanza looks like:
<ejb-reference-description>
<ejb-ref-name>ejb/acc/Acc</ejb-ref-name>
<jndi-name>estore/account</jndi-name>
</ejb-reference-description>
See Deprecated APIs and Features" on page 2-17 for information on deprecated MBean attributes and operations.
Security Data Is Now Written to the config.xml file
The persistence model for the COMMO MBeans changed in this release of WebLogic Server. All security configuration data is now stored in the config.xml file. Existing security configuration data is written to the config.xml file when the server is initially booted. The config.xml file must have write permissions for this upgrade to occur.
Web Resource Is Replaced by URL Resource
The Web resource available in previous releases of WebLogic Server has been replaced by the URL resource. If you wrote a custom Authorization provider that uses the Web resource (instead of the URL resource), enable the Use Deprecated Web Resource attribute. This attribute changes the runtime behavior of the Servlet container to use a Web resource rather than a URL resource when performing authorization.
To use an existing Web resource:
A new keystore implementation is available in this release of WebLogic Server. The keystore retrieves trusted CAs, private keys, and server certificates from JDK keystores. The keystore implementation in this release of WebLogic Server offers several improvements:
By default, WebLogic Server has SSL enabled and the server's identity and trust is established with a demonstration certificate and demonstration and standard (JDK) certificate authorities. The following sections describe how existing identity and trust mechanisms can be used with this release of WebLogic Server.
Custom Keystore Providers Are No Longer Supported
Custom Keystore providers cannot be used with this release of WebLogic Server. Private keys and trusted CAs should be stored in keystores associated with a particular instance of WebLogic Server. For more information about configuring a keystore for a server and loading private keys and trusted CAs into the keystore, see "Configuring Keystores and SSL" in the Security section of the Administration Console online help.
The WebLogic Keystore Provider Is Deprecated
The WebLogic Keystore provider is deprecated in this release of WebLogic Server. If you are using the WebLogic Keystore provider to store private keys and trusted CAs, the server, when first booted with this release of WebLogic Server, will update the SSL MBean in the config.xml file to include the following attribute:
IdentityAndTrustLocations="FilesorKeystoreProviders"
This attribute tells the server to use the 7.x SSL configuration rules instead of the new SSL rules. BEA recommends using this configuration only until you can upgrade to the keystores available in this release of WebLogic Server.
Using Flat Files for Identity and Trust Is Deprecated
Storing identity (private keys and certificates) and trust (certificate authorities) in files is no longer supported. To upgrade to the keystores available in this release of WebLogic Server:
For more information, see "Configuring Keystores and SSL" in the Security section of the Administration Console online help.
In WebLogic Server 7.x, Java clients (fat clients) retrieved trusted CAs from a jks keystore. The following command-line argument specified the pathname to the keystore:
-Dweblogic.security.SSL.trustCAkeystore
If the command-line argument was not specified, WebLogic Server defaulted to the trusted CAs in the JDK jre/lib/security/cacerts keystore.
The way Java clients retrieve trusted CAs has been improved in the following ways:
This release of WebLogic Server still supports the trust command-line argument in WebLogic Server 7.0. As in WebLogic Server 7.0, WebLogic Server defaults to the trusted CAs in the JDK jre/lib/security/cacerts keystore.
To upgrade to the new trust mechanism in this release of WebLogic Server, specify one of the following command-line arguments.
To trust the JDK standard trusted CAs, use:
-Dweblogic.security.TrustKeystore=JavaStandardTrust
To trust the JDK standard trusted CAs and the demo trusted CAs provided by WebLogic Server, use:
-Dweblogic.security.TrustKeystore=DemoTrust
To use a custom keystore, use:
-Dweblogic.security.TrustKeystore=CustomTrust
-Dweblogic.security.CustomTrustKeystorePathname=keystorepathname
The JTS driver has become a non-XA resource. In 7.0 the JTS driver emulated an XA driver by always responding successfully to the XAResource.prepare directive and issuing a one-phase commit on the JDBC connection. In WebLogic Server 8.1, the last-agent commit optimization is used where the non-XA commit operation is used by the transaction manager as the basis of the commit decision. Users may see fewer heuristic exceptions for the case where the JTS driver commit operations fails due to the last-agent protocol semantics. They may also see exceptions if the application attempts to enlist more than one JTS driver in the transaction since the non-XA support limits the number of participating non-XA resources to one.
Configuration checking in WebLogic Server 8.1 is slightly more strict than in 7.0. In 7.0, administrators can configure multiple JMS destinations (not distributed destination memebers) with the same JNDI name. They were also allowed to configure a connection factory having the same JNDI name with default ones. Those are not allowed any more in WebLogic Server 8.1. An existing 7.0 configuration may fail to boot when upgrading to WebLogic Server 8.1.
Several interfaces that were previously marked deprecated have been removed:
Prepared Statement Cache Algorithm
A new prepared statement cache algorithm has been introduced. It removes the least recently used statements from the cache. The old algorithm kept a fixed number of statements in the cache (the first n, where n is the configured size of the cache).If a customer wants to get the old behavior (e.g., if they have the use case that we documented about loading the cache in a startup class), the connection pool can be configured to use the "FIXED" algorithm for the pool.
Pool, JTS/JTA, and RMI Connections
In past releases, pool, JTS/JTA, and RMI connections were handled different. Pool connections waited for 5 seconds before timing out. JTS/JTA connections waited 10 seconds before timing out. RMI Datasource connections were non-blocking.In the WebLogic Server 8.1 release, all connections block for up to 10 seconds before timing out.
WebLogic Server 8.1 automatically updates configuration information read from the 7.0 config.xml file to include WebLogic Server 8.1 information. In order for these changes to be retained between invocations of the server, the config.xml file must be writable. To allow the file to be writable, make a backup copy of your config.xml file from your 7.0 configuration and change the file attributes.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
