bea.com | products | dev2dev | support | askBEA
 Download Docs   Site Map   Glossary 
Search
e-docs > WebLogic Server > WebLogic Server 8.1 Upgrade Guide > Upgrading WebLogic Server 4.5 and 5.1 to Version 8.1

WebLogic Server 8.1 Upgrade Guide

 Previous Next Contents View as PDF  

Upgrading WebLogic Server 4.5 and 5.1 to Version 8.1

Upgrading WebLogic Server 4.5 and 5.1 to version 8.1 is a multi-step process that involves defining web applications and converting your weblogic.properties file(s) into a new XML file format. There are also several specification changes that affect the upgrade process. This chapter addresses the majority of 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 4.5 or 5.1 to WebLogic Server 8.1; to port your applications from WebLogic Server 4.5 or 5.1 to WebLogic Server 8.1; and deploy these applications. Instructions apply to upgrades from both WebLogic Server 4.5 and 5.1 to WebLogic Server 8.1.

Note: Throughout this document the word, upgrade, is used to refer to upgrading to a later version of WebLogic Server and the word, port, is used to refer to moving your applications from an earlier version of WebLogic Server to a later version.

 

Upgrading Your WebLogic Server Configuration: Main Steps

Take the following steps to upgrade from WebLogic Server 4.5 or 5.1 to WebLogic Server 8.1:

  1. Install WebLogic Server 8.1. See the Installation Guide.

    Prior to WebLogic Server 6.0, a separate download was required if you wanted to get 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 of how to enable 128-bit encryption see Enabling 128-Bit Encryption in the Installation Guide.

    Note: Installing the new version in the exact location of the old version is explicitly prohibited by the installer.

  2. Upgrade your server license files. For instructions on how to convert your licenses to the new format, see Upgrading WebLogic Server License Files.
  3. Convert your weblogic.properties file. For instructions on how to convert your weblogic.properties file, see Converting the weblogic.properties File to XML Files and the Console Help documentation.
  4. Enter a name for you new Administration Server in the provided window in the Console. This name is used as the Server Name for the Administration Server. If the name is not specified, the name will be myserver by default.
  5. Enter a directory location for the resulting conversion output configuration. All files and subdirectories created as a result of the conversion of your original domain will be placed in this directory location.
  6. Add classes to your Java system CLASSPATH. For more information see Classloading in WebLogic Server 8.1.
  7. Modify your existing startup scripts to work with WebLogic 8.1. See Modifying Startup Scripts.
  8. Package and port your WebLogic server-side business object implementations (referred to as Web applications beginning with WebLogic Server 6.0) to run on WebLogic 8.1. See Converting Your Existing Applications into Web Applications.
  9. If you need to port EJBs, see Porting and Converting Enterprise JavaBeans Applications.
  10. Upgrade JMS. Many new configuration attributes have been added to JMS since WebLogic Server 4.5. For more information, see Upgrading JMS.

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 Clusters. All servers in the cluster should be running 8.1 since there is no interoperability between 4.5 and 8.1 or between 5.1 and 8.1.

Note: The directory structure in WebLogic Server 8.1 is different from that of 4.5 and 5.1. For complete information on the updated directory structure see Understanding the WebLogic Server Directory Structure in Performing Post-Installation Tasks.

 

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

  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 6.x and 7.x), 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_wlsxx.bea file through e-mail. To update the license.bea file on your system, see Updating Your license.bea File in the Installation Guide.

 

Converting the weblogic.properties File to XML Files

Prior to WebLogic Server 6.0, WebLogic Server releases used a weblogic.properties file to configure applications. In WebLogic Server 8.1, configuration of applications is handled through XML descriptor files and the Administration Console. Converting a weblogic.properties file to the config.xml file creates a new domain for your applications and adds XML files that define how your applications are set up. BEA Systems recommends that you change the name of the default domain name that is created during the conversion so that the name is relevant to your work.

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, and all elements in the domain are children of the domain element. The domain element includes child elements, such as the server, cluster, and application elements. These child elements may 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 existing weblogic.properties file to the appropriate XML file by following these steps:

  1. Start the WebLogic Server 8.1 examples server. For information on starting the WebLogic Server 8.1 examples server, see Starting the Examples, Pet Store, and Workshop Examples Servers in Performing Post-Installation Tasks.

    You will be prompted for a user name and password.

  2. 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.
  3. Use the Console's links to navigate the server's file system and find the root directory of your previous version of WebLogic Server (for example: C:\weblogic). When you have found the correct directory, click on the icon next to it to select it.
  4. If you have additional per server weblogic.properties files or clustering weblogic.properties files in other directories, select them using the provided windows. If you have chosen the correct root directory of your previous version of WebLogic Server, your global weblogic.properties file will be converted regardless of any additional properties files that you select.
  5. Enter a name for your new domain in the provided window in the Console. Click Convert.

When you convert your properties file, the web.xml and weblogic.xml files for the default web application are created for you and placed inside a domain\applications\DefaultWebApp_myserver\WEB-INF directory. The process of 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.

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 The weblogic.properties Mapping Table.

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

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 Starting and Stopping WebLogic Servers in the Administration Guide for more information on scripts and starting servers.

 

Classloading in WebLogic Server 8.1

Earlier versions of 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 for your new WebLogic Server 8.1 domain. If you need to edit it to specify your domain startup preferences, keep the following in mind.

 

WebLogic Server 8.1 J2EE Application Types

Applications on J2EE-compliant servers such as WebLogic Server 8.1 are created and deployed as one of the following four types: Web Applications, Enterprise JavaBeans, Enterprise Archives, and client applications. To port your existing components to WebLogic Server 8.1, create the appropriate J2EE deployment units. For more information on J2EE deployment units, see Deploying Web Applications as Part of an Enterprise Application in Assembling and Configuring Web Applications. Web Applications are usually a collection of servlets, JSPs, and HTML files, packaged as WAR files. Enterprise JavaBeans (packaged as JAR files) are server-side Java components written according to the EJB specification. Enterprise Archives (EAR files) contain all of the JAR and WAR component archive files for an application and an XML descriptor that describes the bundled components. Client Applications are Java classes that connect to WebLogic Server through Remote Method Invocation (RMI). Later sections discuss the aforementioned J2EE deployment units in greater detail.

 

Converting Your Existing Applications into 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 development, these files can be left in an exploded directory format. However, for production situations, it is highly recommended that you bundle your applications into a WAR file as a single Web Application. For more information on Web Applications see Understanding WebLogic Server J2EE Applications, Assembling and Configuring Web Applications, and Web Applications Basics.

The following sections provide information you need to know about porting and deploying Web Applications, including a procedure for porting 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. For detailed instructions on creating the deployment descriptor, see Writing the web.xml Deployment Descriptor in Assembling and Configuring Web Applications.

There is also a WebLogic-specific 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 Writing the WebLogic-Specific Deployment Descriptor. 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 with the appropriate path as specified by the prescribed directory structure under Web Applications Directory Structure" on page 3-10. See Assembling and Configuring Web Applications 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. If you have correctly followed the prescribed directory structure of a Web Application and created the appropriate web.xml and weblogic.xml files, it is strongly recommended that in production environments your applications be bundled together in a Web Application deployed as a WAR file. Once you have bundled your applications into a WAR file, it is important to remove the previously existing directory structure so that WebLogic Server only has one instance of each application.

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.

Deploying Web Applications

To deploy your bundled Web Applications properly you should install the application through the Administration Console. To do so, go to the console home and choose Install Applications under the Getting Started menu. Select the correct WAR file, and it will be installed automatically. If your server is running in development mode, you can also install the WAR file by placing it in the domain\applications directory.

Web Applications should be deployed automatically after they are installed. Check to see that they are deployed under the Deployments node in the left hand pane of the Administration Console.

You can configure certain deployment attributes for your Web Application using the Administration Console. Select the Web Applications node under the Deployments heading. Select your Web Application. Click on the appropriate tab to configure. For more information on setting attributes in the console, see the Web Applications section of the Console Help.

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.

See weblogic.xml Deployment Descriptor Elements in Assembling and Configuring Web Applications.

JavaServer Pages (JSPs) and Servlets

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

Porting a Simple Servlet from WebLogic Server 5.1 to WebLogic Server 8.1

The following procedure ports the simple Hello World Servlet that was provided with WebLogic 5.1 Server to WebLogic Server 8.1.

  1. In WebLogic Server 8.1, create the correct directory structure, 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. Place the HelloWorld.Servlet.java file inside the C:\hello\WEB-INF\classes directory.
  2. Create a web.xml file for this servlet. If you have 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 properly 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 Writing Web Application Deployment Descriptors in Assembling and Configuring Web Applications. A weblogic.xml file is not necessary with such a simple, stand-alone servlet as HelloWorld.

    For more information on weblogic.xml files, see Writing the WebLogic-Specific Deployment Descriptor in Assembling and Configuring Web Applications.

  3. Move the web.xml file from domain\applications\DefaultWebApp_myserver\WEB-INF to C:\hello\WEB-INF\.
  4. Set up your development environment (see Establishing a Development Environment in Developing WebLogic Server Applications for more information) and 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.

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

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

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

 

Porting and Converting Enterprise JavaBeans Applications

The following sections describe Enterprise Java Beans porting and conversion procedures.

EJB Porting Considerations

Consider the following when porting Enterprise JavaBeans to WebLogic Server 8.1.

EJB Porting Recommendations

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

Steps for Porting a 1.0 EJB from WebLogic Server 4.5.x to WebLogic Server 8.1

WebLogic Server 3.1.x, 4.0.x, and 4.5.x supported the EJB 1.0 specification. To port a 1.0 EJB from WebLogic Server 4.5 to WebLogic Server 8.1:

  1. Convert the EJB 1.0 deployment descriptor to either the EJB 1.1 or the EJB 2.0 XML deployment descriptor. You can do this automatically using the DDCreator tool.
  2. Package the deployment descriptor in a JAR file which includes the deployment descriptor's output from step one above and the bean classes.
  3. Run the WebLogic Server EJB compiler (ejbc) to compile the JAR file. The ejbc tool ensures that when the EJB compiles, it conforms to either the EJB 1.1 or EJB 2.0 specifications.
  4. Correct any compliance errors before deploying the EJB in the EJB container.

To ensure EJB 1.1 or 2.0 compliance, make the following changes to the EJB 1.0 beans:

Steps for Porting a 1.1 EJB from WebLogic Server 5.1 to WebLogic Server 8.1

The WebLogic Server 5.1 deployment descriptor 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. For more information about this option, see information on database concurrency in weblogic-ejb-jar.xml Document Type Definitions in Programming WebLogic Enterprise JavaBeans.

The WebLogic Server 8.1 CMP deployment descriptor allows multiple EJBs to be specified and it 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 port a 1.1 EJB from WebLogic Server 5.1 to WebLogic Server 8.1:

  1. Open the Administration Console. From the home page, click on Install Applications under the Getting Started heading.
  2. Locate the JAR file you wish to port by clicking the Browse button, then click Open and then Upload. Your bean should now be automatically deployed on WebLogic Server 8.1.
  3. Run a setEnv script in a client window and set your development environment. (For more information, see Establishing a Development Environment in Developing WebLogic Server Applications.)
  4. 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
  5. 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. If you do wish to convert 1.1 beans to 2.0 beans, see the DDConverter documentation in Programming WebLogic Enterprise JavaBeans for information on how to do this conversion.

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

Porting EJBs from Other J2EE Application Servers

Any EJB that complies with the EJB 1.1 or EJB 2.0 specifications may 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.

 

Creating an Enterprise Application

An Enterprise Application is a JAR file with an EAR extension. An EAR file contains all of the JAR and WAR component archive files for an application and an XML descriptor that describes the bundled components. The META-INF\application.xml deployment descriptor contains an entry for each Web and EJB module, and additional entries to describe security roles and application resources such as databases.

EnterpriseApplicationStagingDirectory\
                                     |
                                     + .jar files
                                     |
                                     + .war files
                                     |
                                     +META-INF\-+
                                                |
                                                + application.xml

To create an EAR file:

  1. Assemble all of the WAR and JAR files for your application.
  2. Copy the WAR and EJB JAR files into the staging directory and then create a META-INF\application.xml deployment descriptor for the application. Follow the directory structure depicted above.

    The application.xml file contains a descriptor for each component in the application, using a DTD supplied by Sun Microsystems. For more information on the application.xml file, see Application Deployment Descriptor Elements in Developing WebLogic Server Applications. Note that if you are using JSPs and want them to compile at run time you must have the home and remote interfaces of the bean included in the classes directory of your WAR file.

  3. Create the Enterprise Archive by executing a jar command like the following in the staging directory: 
    jar cvf myApp.ear *
  4. Click on the Install Applications link under the Getting Started heading in the home page of the console and place the EAR file in the domain\applications directory. For more information on Enterprise Applications, see Packaging Enterprise Applications in Developing WebLogic Server Applications.

 

Understanding J2EE Client Applications

WebLogic Server supports J2EE client applications, packaged in a JAR file with a standard XML deployment descriptor. Client applications in this context are clients that are not Web browsers. They are Java classes that connect to WebLogic Server using Remote Method Invocation (RMI). A Java client can access Enterprise JavaBeans, JDBC connections, messaging, and other services using RMI. Client applications range from simple command line utilities that use standard I/O to highly interactive GUI applications built using the Java Swing/AWT classes.

To execute a WebLogic Server Java client, the client computer needs the weblogic_sp.jar file, the weblogic.jar file, the remote interfaces for any RMI classes and Enterprise Beans that are on WebLogic Server, as well as the client application classes. To simplify maintenance and deployment, it is a good idea to package a client-side application in a JAR file that can be added to the client's classpath along with the weblogic.jar and weblogic_sp.jar files. The weblogic.ClientDeployer command line utility is executed on the client computer to run a client application packaged to this specification. For more information about J2EE client applications, see Packaging Client Applications in Developing WebLogic Server Applications.

 

Upgrading JMS

WebLogic Server 8.1 supports the JavaSoft JMS specification version 1.0.2.

For more information on porting your WebLogic JMS applications, see 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. As stated above, BEA no longer supports this configuration.

To upgrade to Oracle Client Version 9i, or read 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.

 

Additional Porting 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

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.

Deployment

By default, WebLogic Server version 8.1 uses the two-phase deployment model. For more information on this deployment model and other 8.1 deployment features, see WebLogic Server Deployment in Developing WebLogic Server Applications. Therefore, if you deploy a 4.5 or 5.1 application in your 8.1 server, the deployment model is unspecified and, thus, uses a two-phase deployment. For more information, see the Release Notes.

Plug-ins

The communication between the plug-in and WebLogic Server 4.5 and 5.1 is clear text. The plug-ins in WebLogic Server 8.1 support SSL communication between the plug-in and the back-end WebLogic Server.

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

Internationalization (I18N)

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

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

Java Transaction API (JTA)

JTA has changed as follows:

Java Database Connectivity (JDBC)

The following changes have been made to JDBC:

JVM

WebLogic Server 8.1 installs the Java Virtual Machine (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.

RMI

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

Note: For more information, see WebLogic RMI Fea tures and Guidelines in Programming WebLogic RMI.

Security

For specific questions and answers, see the security section of the WebLogic Server Frequently Asked Questions. Upgrading WebLogic Server 4.5 or 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.

The following list of tips and issues regard upgrading from WebLogic Server 4.5 or 5.1 to the WebLogic Server 6.x functionality:

Converting the weblogic.properties File

A large portion of implementing security in the WebLogic Server environment is configuration. To port a current security configuration, convert the Mbean attributes in the weblogic.properties file to XML attributes in the config.xml file using the Administration Console. Details on converting weblogic.properties files are described in the Console Help documentation.

Porting Security Realms

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 port to the new architecture:

Session Porting

WebLogic Server 6.0 and later does not recognize cookies from previous versions because cookie format changed with 6.0. WebLogic Server ignores cookies with the old format, and creates new sessions.

The default name for cookies has changed from 5.1, when it was WebLogicSession. Beginning in WebLogic 6.0, cookies are named JSESSIONID by default.

See weblogic.xml Deployment Descriptor Elements in Assembling and Configuring Web Applications for more information.

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.

Web Components

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

Wireless Application Protocol Applications

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 Writing Web Application Deployment Descriptors in Assembling and Configuring Web Applications.

Writable config.xml File

WebLogic Server 8.1 automatically updates configuration information read from the 6.x config.xml file to include version 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 back-up copy of your config.xml file from your 6.x configuration and change the file attributes.

XML 8.1 Parser and Transformer

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.

To see the explicit differences between the old and new parsers, use a tool contained in the apichange.zip file located on dev2dev Online.

Deprecated APIs and Features

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

Removed APIs and Features

The following APIs and features have been removed:

 

Back to Top Previous Next