Skip navigation.
Downloads | Product Documentation | Support

WebLogic Server 8.1 Upgrade Guide

# Upgrading WebLogic Server 5.1 to Version 8.1

Upgrading WebLogic Server 5.1 to version 8.1 is a multi-step process that involves, among other tasks, using a utility to convert your `weblogic.properties` file(s) into a new XML file format. There are also several specification changes that affect the upgrade process. The following sections address most known upgrade issues, but may omit issues that are unique to a specific environment.

The following sections provide procedures and other information you need to upgrade your system from WebLogic Server 5.1 to WebLogic Server 8.1; to upgrade your applications from WebLogic Server 5.1 to WebLogic Server 8.1; and deploy these applications. Instructions apply to upgrades from both WebLogic Server 5.1 to WebLogic Server 8.1.

To see an example of an application being upgraded from WebLogic Server 5.1 to WebLogic Server 8.1, see Upgrading the Banking Application from WebLogic Server 5.1 to WebLogic Server 8.1.

- Understanding the WebLogic Server 8.1 Directory Structure
- Contents of a Domain Directory
- Upgrading WebLogic Server 5.1 to Version 8.1: Main Steps
- Converting the weblogic.properties File to config.xml
- Upgrading the Banking Application from WebLogic Server 5.1 to WebLogic Server 8.1
- Classloading in WebLogic Server 8.1
- Modifying Startup Scripts
- Converting Applications to Web Applications
- Upgrading Enterprise Java Beans Applications
- Upgrading JMS
- Upgrading Oracle
- Additional Upgrade and Deployment Considerations

# Understanding the WebLogic Server 8.1 Directory Structure

When you upgrade to WebLogic Server 8.1, your servers and applications will be managed in WebLogic Server domains. For a full description of WebLogic Server domains see Overview of WebLogic Server Domains in Configuring and Managing WebLogic Server.

BEA WebLogic recommends that you locate domain directories outside the WebLogic Server installation directory. Domain directories can be in any location that can access the WebLogic Server installation and the JDK.

If you change the location of your domain directory, remember to update any custom tools or scripts relative to the new directory structure. Similarly, if you use a scripted tool for creating domains, change its scripts. The Configuration Wizard is the recommended tool for creating domains, and it can be scripted.

# Contents of a Domain Directory

The configuration of a domain is stored in the `config.xml` file of the domain directory on the Administration Server (for information about Administration Servers and Managed Servers, see Overview of WebLogic Server Domains in Configuring and Managing WebLogic Server). `config.xml` stores the name of the domain and the configuration parameter settings for each server instance, cluster, resource, and service in the domain.

The domain directory also contains default script files that you can use to start the Administration Server and Managed Servers in the domain.

The domain directory should have:

- A root directory with the same name as the domain, such as mydomain or petstore. This directory should contain the following:

- The configuration file (usually `config.xml`) for the domain.
- Any scripts you use to start server instances and establish your environment.
- Optionally, a subdirectory for storing the domain's application files.

# Upgrading WebLogic Server 5.1 to Version 8.1: Main Steps

These general steps are a checklist of issues to consider when upgrading from version 5.1 to version 8.1. For a detailed example of such an upgrade, see Upgrading the Banking Application from WebLogic Server 5.1 to WebLogic Server 8.1.

To upgrade a cluster of server instances, you must install WebLogic Server 8.1 on each computer that hosts server instances. If you are upgrading a server cluster, refer to Setting Up WebLogic Clusters in Using WebLogic Server Clusters for WebLogic Server cluster configuration guidelines.

1. Convert your `WeblogicLicense.class` or a `WebLogicLicense.XML` license file before installing WebLogic Server 8.1. See Upgrading WebLogic Server License Files.
2. Install WebLogic Server 8.1 in a location accessible from the WebLogic Server 5.1 installation directory. See Installing WebLogic Platform.

Prior to WebLogic Server 6.0, a separate download was required if you wanted to use 128-bit encryption instead of 56-bit encryption. WebLogic Server 8.1 has a single download for both 56-bit encryption and 128-bit encryption. For details about how to enable 128-bit encryption see Enabling 128-Bit Encryption in the Installation Guide.

3. Convert your weblogic.properties file to an 8.1 domain configuration using the Convert weblogic.properties utility in the Administration Console, located under Information Resources. For instructions, see Converting the weblogic.properties File to config.xml and the Console Help documentation.
4. Add classes to your Java system CLASSPATH. For more information see Classloading in WebLogic Server 8.1.
5. If you are using custom startup scripts from WebLogic Server 5.1, modify them to point to WebLogic 8.1 Server. See Modifying Startup Scripts.
6. Package your WebLogic Server server-side business object implementations (referred to as Web applications in WebLogic Server 6.0 and later) to run on WebLogic 8.1. See Converting Applications to Web Applications.
7. If you need to upgrade EJBs, see Upgrading Enterprise Java Beans Applications.
8. Upgrade JMS. Many new configuration attributes have been added to JMS since WebLogic Server 5.1. For more information, see Upgrading JMS.
9. Upgrade Security. Many new security features are available in WebLogic Server 8.1. For more information, see Upgrading WebLogic Server License Files.
10. Your application may require additional upgrade steps to account for other factors, for example new parsers and altered APIs. See Additional Upgrade and Deployment Considerations for information about these factors.

For example, if you compile an upgraded application with WebLogic Server 8.1, 8.1 dependencies on JDK 1.4 require that your 8.1 domain reference JDK 1.4 or an equivalent such as JRockit. For more information on upgrading to JRockit, see Upgrading Your JVM to JRockit.

11. Start WebLogic Server 8.1 Administration and Managed Servers, and configure and deploy your application.

For information about starting WebLogic Server 8.1, see Starting and Stopping Servers: Quick Reference. For information about configuring and deploying your application, see Deployment.

## Upgrading WebLogic Server License Files

The Java format license file (`WebLogicLicense.class`) and the XML-format license file (`WebLogicLicense.XML`) are no longer supported. These files were used with earlier releases of WebLogic Server and must be converted to a new format. The new license file is called `license.bea`.

### Converting a WebLogicLicense.class License

If a `WebLogicLicense.class` license file is used in your existing WebLogic Server installation, perform the following tasks before you install WebLogic Server 8.1:

1. Convert the `WebLogicLicense.class` license file to a `WebLogicLicense.XML` file using the licenseConverter utility.
2. Convert the `WebLogicLicense.XML` file as described in Converting a WebLogicLicense.XML License.

### Converting a WebLogicLicense.XML License

To convert a `WebLogicLicense.XML` file to a `license.bea` file (compatible with WebLogic Server 8.1), complete the following steps. Be sure the `WebLogicLicense.XML` license file is available on the machine on which you perform this procedure.

1. Log in to the BEA Customer Support Web site at http://websupport.beasys.com/custsupp.
2. Click the link to update a WebLogic Server license. You may need to scroll down to see the link.
3. Browse and select the pathname for the directory containing the license file to be converted, or enter the pathname in the box provided. Then click Submit License.
4. You will receive the converted `license_wls` `xx``.bea` file through e-mail. To update the `license.bea` file on your system, see "Installing and Updating WebLogic Platform License Files" in Installing WebLogic Platform.

## Converting the weblogic.properties File to config.xml

Prior to WebLogic Server 6.0, WebLogic Server releases used a `weblogic.properties` file to configure applications. In WebLogic Server 8.1, configuration is handled by a domain configuration file, `config.xml`, and by deployment descriptor files. Converting a `weblogic.properties` file to the `config.xml` file creates a WebLogic Server 8.1 domain for your applications and generates the XML files that define how your applications are set up.

The `config.xml` file is an XML document that describes the configuration of an entire Weblogic Server domain. The `config.xml` file consists of a series of XML elements. The `domain` element is the top-level element. The `domain` element includes child elements, such as the `server`, `cluster`, and `application` elements. These child elements often have children themselves. Each element has one or more configurable attributes.

The `weblogic.xml` file contains WebLogic-specific attributes for a Web application. You define the following attributes in this file: HTTP session parameters, HTTP cookie parameters, JSP parameters, resource references, security role assignments, character set mappings, and container attributes.

The deployment descriptor `web.xml` file is defined by the Servlet 2.3 specification from Sun Microsystems. The `web.xml` file defines each servlet and JSP page and enumerates enterprise beans referenced in the Web application. This deployment descriptor can be used to deploy a Web application on any J2EE-compliant application server.

Convert your WebLogic Server 5.1 `weblogic.properties` file to a WebLogic Server 8.1 `config.xml` file following these steps:

1. Shut down the WebLogic Server 5.1 server instance or instances.
2. Start the WebLogic Server 8.1 Examples server.

For information on starting the WebLogic Server 8.1 examples server, see Starting and Stopping Servers: Quick Reference.

You will be prompted for a user name and password.

3. At the home page for the WebLogic Administration Console (for example: `http://localhost:7001/console/index.jsp`) click on the "Convert weblogic.properties" link under the heading Helpful Tools.
4. In the first page of the "Convert weblogic.properties" path ("Step 1 - Locate weblogic root"), browse to select the directory that contains the weblogic.properties file.

The second page of the "Convert weblogic.properties" path appears.

5. From a list of available application directories, select the root directory that contains your application directories. The `weblogic.properties` converter will convert the application directories into a WebLogic Server 8.1 domain.
6. Fill in the remaining text fields. Do not target a directory in the currently running instance of Weblogic Server as Output Directory.

1. Admin Server Name
2. Output Directory
3. WebLogic Home
4. Name for New Domain

7. Click Convert.

When you convert your `weblogic.properties` file, the `web.xml and weblogic.xml` files for the default Web application are created for you and placed inside the `domain\applications\DefaultWebApp_myserver\WEB-INF` directory. Converting your `weblogic.properties` file also creates the `config.xml` file located in `domain`. This file contains configuration information specific to your domain.

Note: The conversion utility described above specifies the Java home location in the `weblogic.xml` file. It reads this location using the `System.getProperty(java.home)`, which means that it will specify the Java home location on which WebLogic Server was started for the conversion.

- It is strongly recommended that you not edit the `config.xml` file directly. Access the configuration through the Administration Console, a command line utility, or programmatically through the configuration API. For details on editing `config.xml`, see WebLogic Server Configuration Reference.
- Security properties are stored in the `fileRealm.properties` file located in domain.
- The `weblogic.common.ConfigServicesDef` API, which provided methods to get properties out of the `weblogic.properties` file, has been removed from this version.

For more procedures for converting your `weblogic.properties` file, see the Console Help documentation.

For a list of which `config.xml, web.xml, or weblogic.xml` attribute handles the function formerly performed by `weblogic.properties` properties, see Mapping weblogic.properties to 6.x config.xml Configuration Attributes.

The startup scripts, which are generated when a `weblogic.properties` file is converted, are named:

- `startdomainName.cmd` (for Windows users)
- `startdomainName.sh` (for UNIX users)

where domainName is the name of your domain directory.

These scripts exist under the domain directory in your WebLogic Server 8.1 distribution and start the Administration Server in the new domain. You may need to edit this startup script to further specify your startup preferences for the domain.See Modifying Startup Scripts.

# Classloading in WebLogic Server 8.1

Before WebLogic Server 6.0, WebLogic Server used the WebLogic classpath property (`weblogic.class.path`) to facilitate dynamic classloading. In WebLogic 6.0 and later, the `weblogic.class.path` is no longer needed. You can now load classes from the Java system classpath.

To include the classes that were formerly specified in `weblogic.class.path` in the standard Java system classpath, set the `CLASSPATH` environment variable, or use the `-classpath` option on the command line as in the following example:

>     java -classpath %CLASSPATH%;%MyOldClassspath% weblogic.Server

where `%`MyOldClasspath`%` contains only the directories that point to your old applications.

# Modifying Startup Scripts

The `weblogic.properties` converter created a new startup script (called `startdomainName.cmd` or `.sh`) for your new WebLogic Server 8.1 domain. If you need to edit this script to specify your domain startup preferences, keep the following in mind.

- The WebLogic classpath is no longer used; use the Java system classpath as described in the preceding section, Classloading in WebLogic Server 8.1.
- WebLogic Server 8.1 is started from the domain directory. Paths in the startup script assume that the script is located in the domain directory.
- It is no longer necessary to include the license file in the classpath.
- There is now a distinction between an Administration Server and Managed Servers (see The Administration Server and Managed Servers in Configuring and Managing WebLogic Server). Scripts that start servers may need to be rewritten according to how you plan to administer your servers. For the new commands and their required arguments, see Starting and Stopping WebLogic Servers in the Configuring and Managing WebLogic Server.

# Converting Applications to Web Applications

In order to convert an application to a Web application and upgrade it to WebLogic Server 8.1, the application's files must be placed within a directory structure that follows a specific pattern. For more information on Web applications see Developing Web Applications for WebLogic Server.

The following sections discuss upgrading and deploying Web applications. They include a procedure for upgrading a simple servlet from WebLogic Server 5.1 to WebLogic Server 8.1.

- XML Deployment Descriptors
- WAR Files
- Session Porting
- JavaServer Pages (JSPs) and Servlets
- Upgrading a Simple Servlet from WebLogic Server 5.1 to WebLogic Server 8.1

## XML Deployment Descriptors

The Web application Deployment Descriptor (`web.xml`) file is a standard J2EE descriptor used to register your servlets, define servlet initialization parameters, register JSP tag libraries, define security constraints, and define other Web application parameters.

There is also a WebLogic-specific Web application deployment descriptor (`weblogic.xml`). In this file you define JSP properties, JNDI mappings, security role mappings, and HTTP session parameters. The WebLogic-specific deployment descriptor also defines how named resources in the `web.xml` file are mapped to resources residing elsewhere in WebLogic Server. For detailed instructions on creating the WebLogic-specific deployment descriptor, see weblogic.xml Deployment Descriptor Elements in Developing Web Applications for WebLogic Server. This file may not be required if you do not need the preceding properties, mappings, or parameters.

Use the `web.xml` and `weblogic.xml` files, in conjunction with the Administration Console, to configure your applications. The XML files can be viewed through any text editor. To edit them, simply make your changes and save the file as `web.xml` or `weblogic.xml`. See Developing Web Applications for WebLogic Server for more information. If you do not want to deploy your applications together as a single Web application, you need to split up the XML files that have been created for you, creating the appropriate XML files specific to each Web application. Each Web application needs a `weblogic.xml` file and a `web.xml` file as well as whichever files you choose to put in it.

## WAR Files

A WAR file is a Web application archive. Use the following command line from the root directory containing your Web application to create a WAR file, replacing `webAppName' with the specific name you have chosen for your Web application:

>     jar cvf webAppName.war *

You now have created a WAR file that contains all the files and configuration information for your Web application.

## Session Porting

WebLogic Server 8.1 does not recognize cookies from previous versions because cookie format changed with WebLogic Server 6.0. WebLogic Server will ignore cookies with the old format and create new sessions. Be aware that new sessions are created automatically.

The default name for cookies has changed from 5.1, when it was `WebLogicSession`. In WebLogic Server 8.1, cookies are named `JSESSIONID` by default.

## JavaServer Pages (JSPs) and Servlets

This section contains information specific to JSPs and servlets that may be pertinent to your applications.

- Some changes will be necessary in code (both Java and HTML) where the code refers to URLs that may be different when servlets and JSPs are deployed in a Web application other than the default Web application. See Administration and Configuration in Programming WebLogic Server HTTP Servlets for more information. If relative URLs are used and all components are contained in the same Web application, these changes are not necessary.
- Only serializable objects may be stored in a session if your application is intended to be distributable.
- You must have converted the properties in your `weblogic.properties` file to XML elements and attributes in `config.xml, web.xml` and `weblogic.xml`. For information on this process, see Converting the weblogic.properties File to config.xml.
- Access control by an ACL has been replaced with security-constraint-based access control in the Web application deployment descriptor.
- Server-side-includes are not supported. You must use JSP to achieve this functionality.
- WebLogic Server 8.1 is fully compliant with the Servlet 2.3 specification.
- Your `web.xml` file should use:

>     weblogic.servlet.proxy.HttpClusterServlet

instead of

>     weblogic.servlet.internal.HttpClusterServlet

and

>     weblogic.servlet.proxy.HttpProxyServlet

instead of

>     weblogic.t3.srvr.HttpProxyServlet

## Upgrading a Simple Servlet from WebLogic Server 5.1 to WebLogic Server 8.1

The following procedure upgrades the Hello World Servlet provided with WebLogic 5.1 Server to WebLogic Server 8.1. The procedures assume that you have both 5.1 and 8.1 installed on a single server, and only 8.1 is running.

1. In WebLogic Server 8.1, create a directory structure for a Web application as described in Administration and Configuration in Programming WebLogic Server HTTP Servlets. This involves creating a root application directory, such as `C:\hello`, as well as a `C:\hello\WEB-INF` directory and a `C:\hello\WEB-INF\classes` directory.
2. Place the `HelloWorld.Servlet.java` file (located in the `WL_HOME\examples\servlets` directory of your 5.1 installation) inside the `C:\hello\WEB-INF\classes` directory.
3. Create a `web.xml` file for this servlet. If you converted your `weblogic.properties` file, a `web.xml` file has already been created for you. If you registered HelloWorldServlet in your `weblogic.properties` file before you converted it, the servlet will be configured in your new `web.xml` file. An XML file can be created with any text editor. The following is an example of a basic `web.xml` file that could be used with the HelloWorldServlet.

>     <!DOCTYPE web-app (View Source for full doctype...)>
>     - <web-app>
>     - <servlet>
>     <servlet-name>HelloWorldServlet</servlet-name>
>     <servlet-class>examples.servlets.HelloWorldServlet</servlet-class>
>     </servlet>
>     - <servlet-mapping>
>     <servlet-name>HelloWorldServlet</servlet-name>
>     <url-pattern>/hello/*</url-pattern>
>     </servlet-mapping>
>     </web-app>

For more information on `web.xml` files, see web.xml Deployment Descriptor Elements in Developing Web Applications for WebLogic Server. A `weblogic.xml` file is not necessary with such a simple, stand-alone servlet as HelloWorld.

For more information on `weblogic.xml` files, see weblogic.xml Deployment Descriptor Elements in Developing Web Applications for WebLogic Server.

4. Move the `web.xml` file from `domain\applications\DefaultWebApp_myserver\WEB-INF` to `C:\hello\WEB-INF\`.
5. Compile the HelloWorldServlet with a command like the following:

>     C:\hello\WEB-INF\classes>javac -d  . HelloWorldServlet.java

This should compile the file and create the correct package structure.

6. The servlet can now be bundled into an archive WAR file with the following command:

>     jar cvf hello.war *

This command will create a`hello.war` file and place it inside the `C:\hello` directory.

7. To install this Web application, start your server and open the Administration Console. Under the Getting Started menu, choose Install Applications. Browse to the newly created WAR file and click Upload.

The servlet should now be deployed and appear under the Web applications node under Deployments, in the left-hand pane of the console.

8. To call the servlet, type the following in your browser URL window: `http://localhost:7001/hello/hello`.

In this case `/hello/` is the context path of the servlet. This is determined by the naming of the WAR file, in this case `hello.war`. The second `/hello` was mapped in the servlet mapping tags inside the `web.xml` file.

# Upgrading Enterprise Java Beans Applications

The following sections describe Enterprise Java Beans upgrade procedures and related information.

## EJB Upgrade Considerations

Consider the following when upgrading Enterprise Java Beans to WebLogic Server 8.1.

- WebLogic Server Version 8.1 supports the Enterprise Java Beans 1.1 and 2.0 specifications. However, the finder expressions feature, which was a WebLogic Server extension to EJB 1.1, is not supported for both the EJB 1.1 and EJB 2.0 specifications.
- EJB 1.1 beans are deployable in WebLogic Server 8.1. However, if you are developing new beans, it is recommended that you use EJB 2.0.`` EJB 1.1 beans can be converted to 2.0 using the DDConverter utility. For more information, see DDConverter in Programming WebLogic Enterprise Java Beans.
- Upgrade EJB 1.0 deployment descriptors to EJB 2.0 by first upgrading them to EJB 1.1 and then using the DDConverter utility to upgrade them to EJB 2.0. Details on the DDConverter utility are provided in the section DDConverter in Programming WebLogic Enterprise Java Beans.
- If `ejbc` has not been run on an EJB, WebLogic Server 8.1 will run `ejbc` automatically when the bean is deployed. You do not need to compile beans with `ejbc` before deploying. If you wish to run `ejbc` during startup, you may do so. See EJB Development Task Guide in Programming WebLogic Enterprise Java Beans.
- An EJB deployment includes a standard deployment descriptor in the `ejb-jar.xml` file. The `ejb-jar.xml` must conform to either the EJB 1.1 DTD (document type definition) or the EJB 2.0 DTD.
- An EJB deployment needs the `weblogic-ejb-jar.xml` file, a WebLogic Server-specific deployment descriptor that includes configuration information for the WebLogic Server EJB container. This file must conform to the WebLogic Server 5.1 DTD or the WebLogic Server 8.1 DTD.
- In order to specify the mappings to the database, container-managed persistence entity beans require a CMP deployment descriptor that conforms to either the WebLogic Server 5.1 CMP DTD, the WebLogic Server 8.1 EJB 1.1 DTD, or the WebLogic Server 8.1 EJB 2.0 DTD.
- In WebLogic Server 8.1 the `max-beans-in-cache` parameter controls the maximum number of beans in the cache for Database concurrency. In earlier WebLogic Server versions, `max-beans-in-cache` was ignored; the size of the cache was unlimited. You may need to increase the size of this parameter.
- Use a fast compiler with `ejbc`.

The WebLogic Server EJB compiler (`weblogic.ejbc`) generates Java code that is then compiled by the Java compiler. By default, WebLogic Server uses the `javac` compiler included with the bundled JDK. The EJB compiler runs much faster when a faster Java compiler is used. Use the `-compiler` option to specify an alternate compiler as in the following example:

>     java weblogic.ejbc -compiler sj pre_AccountEJB.jar AccountEJB.jar

- Correct errors before deploying the EJB on WebLogic Server 8.1.

The WebLogic Server 8.1 EJB compiler (`ejbc`) includes additional verification that was missing from earlier WebLogic Server releases. It is possible that an EJB deployed in a previous WebLogic Server version without error, but WebLogic Server 8.1 finds and complains about the error. These errors must be corrected before the EJB is deployed in WebLogic Server 8.1.

For instance, WebLogic Server 8.1 ensures that a method exists if a transaction attribute is set for that method name. This helps identify a common set of errors where transaction attributes were mistakenly set on non-existent methods.

- Use `TxDataSource`

EJBs should always get their database connections from a `TxDataSource`. This allows the EJB container's transaction management to interface with the JDBC connection, and it also supports XA transactions.

The WebLogic Server 8.1 CMP deployment descriptor (`weblogic-cmp-rdbms.xml`) supports `TxDataSource`s and should be used instead of the WebLogic Server 5.1 CMP deployment descriptor which only specifies a connection pool.

- The following table shows which EJB versions are supported by which versions of WebLogic Server and the CMP deployment descriptor.

  ####

  Table 4-1 Supported Descriptor Combinations

  EJB Version | WebLogic Server Version | The CMP Version
  --- | --- | ---
  Existing WebLogic Server 5.1 deployments use the following combination. EJBs can be deployed without changing descriptors or code in WebLogic Server 8.1.
  1.1 | 5.1 | 5.1
  The following combinations include a WebLogic Server 8.1 CMP deployment descriptor. The WebLogic Server 8.1 EJB 1.1 CMP deployment descriptor allows multiple EJBs to be specified within a single EJB JAR file, and it supports using a `TxDataSource`, which is required when an EJB is enlisted in a two-phase /XA transaction.
  1.1 | 5.1 | 8.1
  1.1 | 8.1 | 8.1
  EJB 2.0 beans always use the WebLogic Server 6.x or 8.1 deployment descriptors.
  2.0 | 6.x | 8.1
  2.0 | 8.1 | 8.1

For more information on Enterprise Java Beans, see Enterprise Java Bean Components and Programming WebLogic Enterprise Java Beans.

## Steps for Upgrading a 1.1 EJB from WebLogic Server 5.1 to WebLogic Server 8.1

The WebLogic Server 5.1 `weblogic.properties` file only allows the exclusive or read-only concurrency options. The database concurrency option is available when upgrading to the WebLogic Server 8.1 `weblogic-ejb-jar.xml` file. See Choosing a Concurrency Strategy in Programming WebLogic Enterprise Java Beans.

The WebLogic Server 8.1 CMP deployment descriptor, `weblogic-cmp-rdbms-jar.xml`, allows multiple EJBs to be specified and supports using a `TxDataSource` instead of a connection pool. Using a `TxDataSource` is required when XA is being used with EJB 1.1 CMP.

To upgrade a 1.1 EJB from WebLogic Server 5.1 to WebLogic Server 8.1:

1. Open the Weblogic Server 8.1 Administration Console. From the home page, click on Install Applications under the Getting Started heading.
2. Locate the JAR file you wish to upgrade using the Browse button, then click Open and Upload. Your bean should automatically deploy on WebLogic Server 8.1.
3. Compile all the needed client classes. For example, using the Stateless Session Bean sample that was provided with WebLogic Server 8.1, you would use the following command:

>     javac -d %CLIENTCLASSES% Trader.java TraderHome.java TradeResult.java Client.java

4. To run the client, enter this command:

>     java -classpath %CLIENTCLASSES%;%CLASSPATH% examples.ejb.basic.statelessSession.Client

This command ensures that the EJB interfaces are referenced in your client's classpath.

## Steps for Converting an EJB 1.1 to an EJB 2.0

To convert an EJB 1.1 bean to an EJB 2.0 bean, you can use the WebLogic Server DDConverter utility.

BEA Systems recommends that you develop EJB 2.0 beans in conjunction with WebLogic Server 8.1. For 1.1 beans already used in production, it is not necessary to convert them to 2.0 beans. EJB 1.1 beans are deployable with WebLogic Server 8.1.

The basic steps required to convert a simple CMP 1.1 bean to a 2.0 bean are as follows:

1. Make the bean class abstract.

EJB 1.1 beans declare CMP fields in the bean. CMP 2.0 beans use abstract `getXXX` and `setXXX` methods for each field. For instance, 1.1 beans will use `public String name`. EJB 2.0 beans should use `public abstract String getName()` and `public abstract void setName(String n)`. With this modification, the bean class should now read the container-managed fields with the `getName` method and update them with the `setName` method.

2. Any CMP 1.1 finder that used `java.util.Enumeration` should now use `java.util.Collection.` CMP 2.0 finders cannot return `java.util.Enumeration`. Change your code to reflect this:

>     public Enumeration findAllBeans()
>         Throws FinderException, RemoteException;

becomes:

>     public Collection findAllBeans()
>         Throws FinderException, RemoteException;

3. Run DDConverter on the JAR and specify 2.0 output. See DDConverter in Programming WebLogic Enterprise Java Beans.

## Porting EJBs from Other J2EE Application Servers

Any EJB that complies with the EJB 1.1 or EJB 2.0 specifications can be deployed in the WebLogic Server 8.1 EJB container. Each EJB JAR file requires an `ejb-jar.xml` file, a `weblogic-ejb-jar.xml` deployment descriptor, and a CMP deployment descriptor if CMP entity beans are used. The WebLogic Server EJB examples located in `samples\examples\ejb11` and `samples\examples\ejb20` of the WebLogic Server distribution include sample weblogic deployment descriptors.

# Upgrading JMS

WebLogic Server 8.1 supports the JavaSoft JMS specification version 1.0.2.

- Customers running Weblogic Server 5.1 SP07 or SP08 should contact BEA Support before upgrading existing JDBC stores to version 8.1.
- In order to upgrade object messages, the object classes need to be in the Weblogic Server 8.1 server CLASSPATH.
- For destinations that are not configured in Weblogic Server 8.1, the upgraded messages will be dropped and the event will be logged.

To upgrade your WebLogic Server JMS applications, see the procedures in Porting WebLogic JMS Applications in Programming WebLogic JMS. Note that WebLogic Events are deprecated and are replaced by JMS messages with NO_ACKNOWLEDGE or MULTICAST_NO_ACKNOWLEDGE delivery modes. Each of these delivery modes is described in WebLogic JMS Fundamentals in Programming WebLogic JMS.

# Upgrading Oracle

BEA Systems, mirroring Oracle's support policy, supports the Oracle releases listed in the Platform Support for WebLogic jDriver JDBC Drivers on the WebLogic Server Certifications page. BEA no longer supports the following Oracle client versions: 7.3.4, 8.0.4, 8.0.5, and 8.1.5.

To use the Oracle Client Version 7.3.4, use the backward compatible oci816_7 shared library.

For detailed documentation on the WebLogic jDriver and Oracle databases, see Configuring WebLogic jDriver for Oracle in Installing and Using WebLogic jDriver for Oracle.

For supported platforms, as well as DBMS and client libraries, see the BEA Certifications Page. The most current certification information will always be posted on the Certifications page.

# Upgrading the Banking Application from WebLogic Server 5.1 to WebLogic Server 8.1

In the following procedures it is assumed that you have WebLogic Server 5.1 and 8.1 both installed on a single computer.

Use the following three main steps to upgrade the banking application from WebLogic Server 5.1 to WebLogic Server 8.1:

- Set Up the Banking Application on WebLogic Server 5.1
- Convert the weblogic.properties File
- Configure the Banking Application for WebLogic Server 8.1

## Set Up the Banking Application on WebLogic Server 5.1

1. Download the banking application from the link on http://dev2dev.bea.com/products/wlserver61/tutorials/wls_migration.jsp.
2. Follow the steps in the tutorial in the ZIP file with the banking application to install the banking application on WebLogic Server 5.1.
3. Shut down the instance of WebLogic Server 5.1.

## Convert the weblogic.properties File

The conversion utility writes the properties in your WebLogic Server 5.1 `weblogic.properties` file to a WebLogic Server 8.1 domain configuration file, `config.xml`. For more information about domains in WebLogic Server, see WebLogic Server Configuration Reference.

Use the WebLogic 8.1 Administration Console to convert the WebLogic Server 5.1 application's `weblogic.properties` file.

1. Launch the WebLogic Server 8.1 Examples Server.

1. In a command console, navigate to `WL_HOME\samples\domains\examples`, where `WL_HOME` is your WebLogic Server installation directory.
2. Run the script that sets up the Examples environment. In Windows, enter `setExamplesEnv.cmd`. In Unix, use `setExamplesEnv.sh`.
3. Start the Examples Server. In Windows, enter `StartExamplesServer.cmd`. In Unix, use `StartExamplesServer.sh`.

2. In the WebLogic Server Examples page that the Examples Server launches, click the Administration Console link.
3. Log in to the Administration Console.
4. Access the conversion utility by clicking "Convert weblogic.properties" on the left-hand side of the Administration Console.

The conversion utility is a sequence of screens that begins with "Step 1 - Locate weblogic root."

5. In the "Step 1 - Locate weblogic root" screen, select the directory that contains the `weblogic.properties` file.

The second page of the "Convert weblogic.properties" path appears.

6. Select the root directory of your 5.1 application (that is, the directory that contains all of the application files and subdirectories).
7. Fill in the remaining text fields.

1. Admin Server Name: "`migrationserver`"
2. Output Directory "`c:\banco`"
3. WebLogic Home
4. Name for New Domain "`migrationdomain`"

8. Click Convert.

The `weblogic.properties` converter converts the application directories in your root directory into a WebLogic Server 8.1 domain. The Administration Console displays the results of the conversion:

>     New Domain name is migrationdomain

>     *************************************

>     Server Name is migrationserver

>     This server doesn't belong to any cluster

>     *************************************

>     Converting Server properties

>     Converting Server Debug Properties

>     Converting WebServer properties

>     Converting WebApp Component Properties

>     Converting JDBC Specific properties

>     Converting CORBA IIOP properties

>     Converting EJB Specific Properties

>     --- Warning Source File D:\510sp12\migrationserver\app_banking.jar does not exist copy the correct file manually after conversion to C:\banco\applications

>     Converting StartupClass properties

>     Converting Shutdown Class properties

>     Converting MailSession Properties

>     Converting FileT3 properties

>     Converting JMS properties

>     Converting Security Properties

>     Converting the PasswordPolicy properties

>     Converting User Group and ACL properties

>     Creating webApp for the servlets registerd in the properties file

>     Startup Scripts for the Server are created in the ResultDir C:\banco

>     Conversion successful.

## Configure the Banking Application for WebLogic Server 8.1

This section discusses the two main steps needed to deploy and run the banking application on WebLogic Server 8.1:

- Edit the startmigration Script in the banking application's directory.
- Copy Banking Application Files to the Output Directory specified in the `weblogic.properties` converter.

### Edit the startmigration Script

The `weblogic.properties` conversion utility generated a script called `startmigrationdomain` for starting up the banking application's domain. Edit this script to specify additional variables needed to run the upgraded banking application in this new 8.1 domain.

1. Edit the `startmigrationdomain` script, adding the following variables:

`set APPLICATIONS=%WL51_HOME%\config\migrationdomain\applications`

`set CLIENT_CLASSES=%WL51_HOME%\config\migrationdomain\clientclasses`

`set SERVER_CLASSES=%WL51_HOME%\config\migrationdomain\serverclasses`

`set BANKING_WEBAPP_CLASSES=D:\banking\510sp12\migrationserver\serverclasses\examples\tutorials\migration\banking`

`set CLOUDSCAPE_CLASSES=%WL51_HOME%\samples\eval\cloudscape\lib\cloudscape.jar`

2. Append these variables to the classpath in `startmigrationdomain`:

`CLASSPATH=...%APPLICATIONS%;%CLIENT_CLASSES%;%SERVER_CLASSES%;%BANKING_WEBAPP_CLASSES%;%CLOUDSCAPE_CLASSES%`

3. Add the following setting to the `startmigrationdomain` script, making sure to add it before the final `weblogic.Server`:

`-Dcloudscape.system.home=WL51_HOME\eval\cloudscape\data`

### Copy Banking Application Files to the Output Directory

Copy the application JAR file and the Web application classes and files to the banking application directory.

1. Copy `AccountDetail.jsp`, `error.jsp`, and `login.html` to `C:\banco\applications\DefaultWebApp_migrationserver`.
2. Copy `app_banking.jar` to `C:\banco\applications\`.
3. Copy `AccountDetail.jsp`, `error.jsp`, and `login.html` to `C:\banco\applications\DefaultWebApp_migrationserver`.
4. Copy `BankAppServlet.class` into `C:\banco\applications\DefaultWebApp_migrationserver\WEB-INF\classes.`

## Deploy and Run the Banking Application

Start the server for the migration domain by navigating to `c:\banco\` in a command console and entering the command `startmigration`.

To use the application, browse to `http://localhost:7001/banking`.

Log in using the following:

username: `system`

password: `password`

account: `1000`

# Additional Upgrade and Deployment Considerations

The following sections provide additional information that may be useful when you deploy applications on WebLogic Server 8.1. Deprecated features, upgrades, and the important changes that have been made in WebLogic Server 8.1 are noted.

Note: WebLogic Server 8.1 uses PointBase 4.2 as a sample database and does not bundle the Cloudscape database.

- Applications and Managed Servers
- Reset Default Mime Type in weblogic.xml
- Two-Phase Deployment Is the Default Deployment Model
- Changes to Internationalization (I18N) Log Files
- 8.1 Classes Must Be Built Under JDK 1.4
- Support for Java Transaction API (JTA)
- Changes to Java Database Connectivity (JDBC)
- Upgrading Your JVM to JRockit
- Changes to JSPs
- JVM
- Plug-ins Support SSL Communication
- Default Queue Names Have Changed
- Tips for Using RMI
- Security
- Standalone HTML and JSPs
- Web Components
- Define MIME Types for Wireless Application Protocol Applications in web.xml
- XML 8.1 Parser and Transformer Are Updated
- Deprecated APIs and Features
- Removed APIs and Features

## Applications and Managed Servers

By default, applications are deployed to the Administration Server. However, in most cases, this is not good practice. You should use the Administration Server only for administrative purposes. Use the Administration Console to define new Managed Servers and associate the applications with those servers. For more information, see Using WebLogic Server Clusters and Overview of WebLogic System Administration in the Administration Guide.

## Reset Default Mime Type in weblogic.xml

WebLogic Server 5.1 provided the `weblogic.httpd.defaultMimeType` parameter to set the default mime-type for a Web application. The default value in 5.1 was `text/plain`.

WebLogic Server 8.1 replaces the parameter with the `default-mime-type` element in `weblogic.xml`, with the default value `null`.

The `weblogic.properties` conversion tool does not migrate this parameter, so if you have it set, you have to reset it manually.

A sample configuration of the `default-mime-type` element in `weblogic.xml`:

`<weblogic-web-app>`

`<container-descriptor>`

`<default-mime-type>text/plain</default-mime-type>`

`</container-descriptor>`

`</weblogic-web-app>`

## Two-Phase Deployment Is the Default Deployment Model

By default, WebLogic Server version 8.1 uses a two-phase deployment model includes a prepare phase and an activate phase, which helps prevent inconsistent server states by allowing deployments to be validated before being committed to the server. For more information on this deployment model and other 8.1 deployment features, see Deploying WebLogic Server Applications. If you deploy a 5.1 application in WebLogic Server 8.1 without specifying the deployment model, the server will use the two-phase deployment. For more information, see the WebLogic Server 8.1 Release Notes.

## FileServlet Behavior Has Changed

In WebLogic Server 6.1 Service Pack 2 and later, the behavior of FileServlet, which is the default servlet for a Web Application, has changed. FileServlet now includes the SERVLET_PATH setting for determining the source filename. This setting makes it possible to explicitly only serve files from specific directories by mapping the FileServlet to `/dir/*` etc.

See Setting Up a Default Servlet in Developing Web Applications for WebLogic Server.

## Changes to Internationalization (I18N) Log Files

Several internationalization and localization changes have been made in this version:

- Changes to the log file format affect the way that messages are localized. The new message format also has additions to the first line: begin marker, machine name, server name, thread id, user id, tran id, and message id.
- A new internationalized logging API enables users to log messages in the server and clients.
- Clients log to their own logfiles, which are in the same format as the server logfiles, with the exception of the servername and threadid fields.
- `LogServicesDef` is deprecated. Instead, use the internationalized API or `weblogic.logging.NonCatalogLogger` (when internationalization is not required).

For details on internationalization in this version, see the Internationalization Guide.

## 8.1 Classes Must Be Built Under JDK 1.4

WebLogic Server 8.1 has dependencies on JDK 1.4. If you compile an application after putting the 8.1 weblogic.jar in your classpath, the classes must be built under JDK 1.4. This means that your server start script (or `config.xml`, or environment setting) must reference JRockit or JDK 1.4.x.

## Support for Java Transaction API (JTA)

JTA has changed as follows:

- WebLogic Server 8.1 supports the JTA 1.0.1 specification. Updated JTA documentation is provided in Programming WebLogic JTA.
- Based on the inclusion of support for JTA, the JTS JDBC driver (with properties in `weblogic.jts.*` and URL `jdbc:weblogic:jts`:..) has been replaced by a JTA JDBC/XA driver. Existing properties are available for backward compatibility, but you should change the class name and properties to reflect the JTS to JTA name change.

## Changes to Java Database Connectivity (JDBC)

The initial capacities set for JDBC connection pools in WebLogic Server 5.1 are not persisted in the `config.xml` generated by the `weblogic.properties` converter utility.

The following changes have been made to JDBC:

- The WebLogic T3 API was deprecated in WebLogic Server 6.1; use the RMI JDBC driver in its place.
- The`weblogic.jdbc20.*` packages are being replaced with `weblogic.jdbc.*` packages. All WebLogic JDBC drivers are now compliant with JDBC 2.0.
- If you have a current connection and are using a `preparedStatement`, and the stored procedure gets dropped in the DBMS, use a new name to create the stored procedure. If you recreate the stored procedure with the same name, the `preparedStatement` will not know how to access the newly created stored procedure—it is essentially a different object with the same name.

## Upgrading Your JVM to JRockit

When you upgrade a domain to WebLogic Server 8.1, consider upgrading your JVM to JRockit. WebLogic JRockit is a JVM designed for running server-side applications in Windows and Linux running on Intel architectures. For server-side applications, JRockit has these advantages over other virtual machines:

- It employs adaptive optimization, which detects and removes bottlenecks in the deployed application.
- It is designed specifically for the special requirements of server-side applications, which tend to be parallel and thread-intensive, to run for longer periods of time, and not to use graphical interfaces.
- You can monitor JRockit using the WebLogic Server Administration Console.

To switch a WebLogic Server domain to the JRockit JVM:

1. In the server start scripts, set `JAVA_HOME` (or equivalent) shell variables to point to the JRockit root directory. For example, change:

>     @rem Set user-defined variables.

>     set JAVA_HOME=WL_HOME\jdk131

where `WL_HOME` is the WebLogic Server 5.1 installation directory, to

>     @rem Set user-defined variables.

>     set JAVA_HOME=WL_HOME\jrockit81_141_02

where `WL_HOME` is the WebLogic Server 8.1 installation directory.

2. Change the domain's `config.xml` to use the JRockit `javac.exe`. For example, change

>     JavaCompiler="WL_HOME\jdk131\bin\javac"

where `WL_HOME` is the WebLogic Server 5.1installation directory, to

>     JavaCompiler=WL_HOME\jrockit81_141_02\bin\javac"

where `WL_HOME` is the WebLogic Server 8.1 installation directory.

3. Remove from server start scripts any switches specific to the Sun JVM. For example, from the start command:

>     echo on "%JAVA_HOME%\bin\java" -hotspot .... weblogic.Server

delete "`-hotspot`".

4. Start and configure JRockit. See the Starting and Configuring the WebLogic JRockit JVM section for the appropriate version of the JRockit documentation.

For JRockit platform and user information, see the appropriate version of the JRockit User Guide.

## Changes to JSPs

The following sections detail changes to JSP behavior in WebLogic Server 8.1.

### Error Handling

The behavior of the JSP include directive has changed between WebLogic Server 5.1 and the current version. In versions through WebLogic Server 5.1, the JSP include directive logged a Warning-level message if it included a non-existent page. In WebLogic Server 6.0 and later, it reports 500 Internal Server Error in that case.You can avoid the error by placing an empty file at the referenced location.

### Null Requests

Due to a change in the JSP specification, null request attributes now return the string "null" instead of an empty string. WebLogic Server versions since 6.1 contain a new flag in `weblogic.xml` called `printNulls` which is true by default, meaning that returning "null" is the default. Setting `printNulls` to false ensures that expressions with "null" results are printed as an empty string, not the string "null."

An example of configuring the `printNulls` element in `weblogic.xml`:

`<weblogic-web-app>`

`<jsp-param>`

`<param-name>printNulls</param-name>`

`<param-value>false</param-value>`

`</jsp-param>`

`</weblogic-web-app>`

## JVM

WebLogic Server 8.1 installs both the Java Virtual Machine (JVM), JDK 1.4.1, and the JRockit JVM with the server installation. The `setenv.sh` scripts provided with the server all point to the JDK 1.4.1 JVM. The latest information regarding certified JVMs is available at the Certifications Page. For information about upgrading to JRockit, see Upgrading Your JVM to JRockit.

## Plug-ins Support SSL Communication

The communication between the proxy Plug-In and WebLogic Server 5.1 is clear text. WebLogic Server 8.1 supports SSL communication between the plug-ins (Apache, Microsoft IIS, and Netscape) and the back-end WebLogic Server.

To upgrade an Apache, Microsoft IIS, or Netscape plug-in, copy the new plug-in over the old one and restart the IIS, Apache, or iPlanet Web server.

For more information about 8.1 proxy Plug-Ins, see Using Web Server Plug-Ins With WebLogic Server.

## Default Queue Names Have Changed

Default names for execute queues have changed in WebLogic Server 8.1. If you upgrade a configuration that specifies execute queues, the default queue names will automatically alias the new queue names.

####

Table 4-2 Queue Names

Pre-8.1Default Queue Names | WebLogic Server 8.1 Default Queue Names
--- | ---
`default` | `weblogic.kernel.Default`
`__weblogic_admin_html_queue` | `weblogic.admin.RMI`
`__weblogic_admin_rmi_queue` | `weblogic.admin.HTTP`

## Tips for Using RMI

The following tips are for users upgrading to WebLogic Server 8.1 who used RMI in their previous version of WebLogic Server:

- Re-run the WebLogic RMI compiler, `weblogic.rmic`, on any existing code to regenerate the wrapper classes so they are compatible with WebLogic Server 8.1.
- Use `java.rmi.Remote` to tag interfaces as remote. Do not use `weblogic.rmi.Remote.`
- Use `java.rmi.*Exception` (e.g.,`import java.rmiRemoteException;`). Do not use `weblogic.rmi.*Exception`.
- Use JNDI instead of `*.rmi.Naming.`
- Use `weblogic.rmic` to generate dynamic proxies and bytecode; with the exception of RMI IIOP, stubs and skeletons classes are no longer generated.

Note: For more information, see Using the WebLogic RMI Compiler in Programming WebLogic RMI.

- Use `weblogic.rmi.server.UnicastRemoteObject.exportObject()` to get a stub instance.
- The RMI examples have not currently been updated to use java.rmi.* and JNDI. The examples will be revised to reflect `java.rmi.*` and JNDI in a future release.

## Security

Upgrading WebLogic Server 5.1 to WebLogic Server 8.1 with the WebLogic Server 8.1 security functionality is a two-step process involving first upgrading to the WebLogic Server 6.x security functionality and then upgrading from WebLogic Server 6.x to WebLogic Server 8.1.

See Upgrading Security Realms from WebLogic Server 5.1 to 6.1 and Upgrading WebLogic Server 6.x Security to Version 8.1.

See also the security section of the WebLogic Server Frequently Asked Questions.

### Upgrading Security Realms from WebLogic Server 5.1 to 6.1

In WebLogic 6.x, WebLogic Server provides a new management architecture for security realms. The management architecture implemented through MBeans allows you to manage security realms through the Administration Console. If you have a security realm from a previous release of WebLogic Server, use the following information to upgrade to the new architecture:

- If you are using the Windows NT, UNIX, or LDAP security realms, use the Convert `weblogic.properties` option under Information and Resources in the Administration Console to convert the security realm to the 6.1 architecture. Note that you can view users, groups, and ACLs in a Windows NT, UNIX, or LDAP security realm in the Administration Console. However, you still need to use the tools in the Windows NT, UNIX, or LDAP environments to manage users and groups.
- If you are using a custom security realm, follow the steps in Installing a Custom Security Realm in the section called Specifying a Security Realm in the Administration Guide to specify information about how the users, groups, and optional ACLs are stored in your custom security realm.
- The Delegating security realm is no longer supported. If you are using the Delegating security realm, you will have to use another type of security realm to store users, groups, and ACLs.
- If you are using the RDBMS security realm, use one of the following options to convert the security realm:

- If you did not change the source for the RDBMS security realm, follow the steps in Configuring the RDBMS Security Realm in the section called Specifying a Security Realm in the Administration Guide to instantiate a new class for your existing RDBMS security realm and define information about the JDBC driver being used to connect to the database and the schema used by the security realm. In this case, you are creating a MBean in WebLogic Server for the RDBMS security realm.
- If you customized the RDBMS security realm, convert your source to use the MBeans. Use the code example in the `\samples\server\src\examples\security\rdbmsrealm` directory as a guide to converting your RDBMS security realm. Once you have converted your RDBMS security realm to MBeans, follow the instructions in Configuring the RDBMS Security Realm in the section called Specifying a Security Realm in the Administration Guide to define information about the JDBC driver being used to connect to the database and the schema used by the security realm.

- The name of the default security realm changed from `WLPropertyRealm` to the File realm. Realm attributes are now stored in the `fileRealm.properties` file instead of the `weblogic.properties` file.
- Redefine your realm and authorization attributes through the Administration Console. The resulting information is stored in the `fileRealm.properties` file.
- It is highly recommended that at the end of installation, you check all security settings to make sure they are the appropriate ones for their environment.
- ACLs can no longer be used to specify security for stand-alone servlets because stand-alone servlets have been completely replaced by Web applications. Web applications can only be secured using the Web application's deployment descriptors as defined in the Servlet 2.3 specification.

### Upgrading WebLogic Server 6.1 Security to Version 8.1

Once you have configured WebLogic Server to use the 6.1 security functionality, see Upgrading WebLogic Server 6.x to Version 8.1 to read about how to upgrade to the WebLogic Server 8.1 security functionality.

## Standalone HTML and JSPs

In the original domain provided with WebLogic Server 8.1, as well as in any domains that have been created using the `weblogic.properties` file converter, `domain\applications\DefaultWebApp_myserver` directory is created. This directory contains files made available by your Web server. You can place HTML and JSP files here and make them available, separate from any applications you install. If necessary, you can create subdirectories within the `DefaultWebApp_myserver` directory to handle relative links, such as image files.

## URIs with Extra Spaces Result in a 404

Previous versions of WebLogic Server resolved URIs that contained extra spaces. WebLogic Server 8.1 no longer resolves extra spaces, and a URI request that contains extra spaces will result in a 404.

For example, `http://server:port/mywebapp/foo%20%20` used to resolve to the resource `foo` in the Web application "mywebapp," but beginning with 8.1 it no longer does.

## Web Components

The following tips are for users upgrading to WebLogic Server 8.1 who used Web components in their previous version of WebLogic Server:

- All Web components in WebLogic Server now use Web applications as the mechanism for defining how WebLogic Server serves up JSPs, servlets, and static HTML pages. In a new installation of WebLogic Server, the server will configure a default Web application. Customers upgrading to WebLogic Server 8.1 should not need to perform any registrations because this default Web application closely approximates the document root, the JSPServlet, and servlet registrations performed using the `weblogic.properties` file contained in earlier versions.
- SSI is no longer supported.
- URL ACLs are deprecated. Use Servlet 2.3 features instead.
- Some information has moved from `web.xml` to `weblogic.xml`. This reorganization allows a third-party Web application based strictly on Servlet 2.3 to be deployed without modifications to its J2EE standard deployment descriptor (`web.xml`). WebLogic Server 5.1 style settings made in the `web.xml` file using `<context-param>` elements are supported for backward compatibility, but you should adopt the new way of deploying. The following sets of parameters previously defined in `web.xml` are now defined in `weblogic.xml`:
  JSP Parameters (`keepgenerated, precompile compileCommand, verbose, packagePrefix, pageCheckSeconds, encoding`)
  HTTP sessionParameters (`CookieDomain, CookieComment, CookieMaxAgeSecs, CookieName, CookiePath, CookiesEnabled, InvalidationIntervalSecs, PersistentStoreDir, PersistentStorePool, PersistentStoreType, SwapIntervalSecs, IDLength, CacheSize, TimeoutSecs, JDBConnectionTimeoutSecs, URLRewritingEnabled`)

For more information, see Deploying Web Applications in Developing Web Applications for WebLogic Server.

## Define MIME Types for Wireless Application Protocol Applications in web.xml

To run a Wireless Application Protocol (WAP) application on WebLogic Server 8.1, you must now specify the MIME types associated with WAP in the `web.xml` file of the Web application. In WebLogic Server 5.1, MIME types were defined in the `weblogic.properties` file. For information on required MIME types see Programming WebLogic Server for Wireless Services. For information on creating and editing a `web.xml` file, see web.xml Deployment Descriptor Elements in Developing Web Applications for WebLogic Server.

## XML 8.1 Parser and Transformer Are Updated

The built-in parser and transformer in WebLogic Server 8.1 have been updated to Xerces 1.4.4 and Xalan 2.2, respectively. If you used the APIs that correspond to older parsers and transformers that were shipped in previous versions of WebLogic Server, and if you used classes, interfaces, or methods that have been deprecated, you might receive deprecation messages in your applications .

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.

The WebLogic Server 8.1 distribution no longer includes the unmodified Xerces parser and Xalan transformer in the `WL_HOME``\server\ext\xmlx.zip` file.

## Deprecated APIs and Features

The following APIs and features are deprecated in anticipation of future removal from the product:

- WebLogic Events

WebLogic Events are deprecated and should be replaced by JMS messages with NO_ACKNOWLEDGE or MULTICAST_NO_ACKNOWLEDGE delivery modes. See Non-transacted session in Programming WebLogic JMS for more information.

- WebLogic HTMLKona
- WebLogic JDBC t3 Driver
- WebLogic Enterprise Connectivity
- WebLogic Time Services is deprecated and should be replaced by JMX Timer Service. For documentation of JMX Timer Service, see Interface TimerMBean and Class Timer.
- WebLogic Workspaces
- Zero Administration Client (ZAC) is deprecated and should be replaced by JavaWebStart.
- `-Dweblogic.management.host`
- `weblogic.deploy` is deprecated in this release of WebLogic Server 8.1 and is replaced by `weblogic.Deployer`. For more information, see Deploying WebLogic Server Applications.
- `weblogic.management.tools.WebAppComponentRefreshTool` and `weblogic.refresh` are both deprecated in this release of WebLogic Server 8.1. They have been replaced by `weblogic.Deployer`.
- Five WebLogic-specific context parameters supported by the Web application container have been deprecated:

- `weblogic.httpd.servlet.reloadCheckSecs` (has been replaced with the `weblogic.xml` `servlet-reload-check-secs`).
- `weblogic.httpd.servlet.classpath` (instead use the manifest classpath, or WEB-INF/lib or WEB-INF/classes, or virtual directories).
- `weblogic.httpd.clientCertProxy` (not yet replaced in `weblogic.xml`).
- `weblogic.httpd.defaultServlet` (instead define a `servlet-mapping` with pattern=/ in `weblogic.xml`).
- `weblogic.httpd.inputCharset` (instead use `weblogic.xml` `charset-params`).

For more information about `weblogic.xml`, see weblogic.xml Deployment Descriptor Elements in Developing Web Applications for WebLogic Server.

## Removed APIs and Features

The following APIs and features have been removed:

- The old administrative console GUI
- The Deployer Tool
- WebLogic Beans
- WebLogic jHTML
- WebLogic Remote
- WorkSpaces
- WebLogic Server Tour
- T3Client
- Jview support
- SSI
- Weblogic Bean Bar
- RemoteT3
- Jview support
- Weblogic COM

This feature relied on the Microsoft JVM (Jview), which is no longer supported.