Welcome!

Weblogic Authors: RealWire News Distribution, PR.com Newswire, Mark O'Neill

Related Topics: Java, Weblogic, Oracle

Java: Article

Thought Process on Upgrading WebLogic Server to 11g

Best practices for moving your J2EE applications to WebLogic Server 11g

Modern enterprise IT infrastructure must keep pace with dynamic needs. As business changes, it allows customers to react quickly to maintain a competitive edge in the marketplace, often by leveraging new technologies to improve the bottom-line performance. Oracle WebLogic Server11g provides customers with expanded capabilities for interoperability, improvements in implementation and maintenance, and a wide array of performance enhancements. Customers can gain significant cost savings in operations, development and license management.

Based on our experience acquired in a large-scale enterprise J2EE project, here are some of the best practices, known issues, and practical tips to make the upgrading work efficiently. This article contains information for technical managers, administrators and developers looking for the latest business and technical details about WebLogic upgradation.

Introduction
Upgrading to new versions can be challenging task, but it's done for linear scalability, continuous enhanced availability, efficient manageability and automatic/dynamic infrastructure provisioning at a low cost. Upgradation allows customers to stay up-to-date with an Oracle product and access support. Whether you are currently using WebLogic Server 8.x or an earlier version, there are many reasons for moving to WebLogic Server 11g, for example, you can reduce high software ownership and maintenance costs, and, most important, it helps customers focus more strongly on their core competency. As a result, customer IT departments are upgrading to meet the business needs and maintain a competitive edge in the market place.

For instance, upgrading from WebLogic Server 7.0 or 8.1 to 11g might involve some issues, e.g., you have to make your J2EE application(s) compatible with JDK 1.6.

Oracle published an excellent upgrade guide entitled "Upgrading WebLogic Application Environments" and provided two options for upgrading. They are "Upgrade Wizard" and "command-line "weblogic.upgrade". The Oracle Upgrade guide provides step-by-step instructions on how to upgrade the WebLogic Server environment.

Here is a case study on migrating a large-scale J2EE system running on the WebLogic Server 8.1 SP4 platform to WebLogic Server 11g.

Steps to Upgrade
To upgrade the application, we decided to carry out the process in phases. The first phase was to upgrade the application environment using the WebLogic Upgrade Wizard. In the next phase we adopted our build and deployment process. We could manually build and run our application under WebLogic Server 11g. In the last phase we automated the build and deployment process and added support for clustered WebLogic Server instances. The upgradation to WebLogic 11g was first done in the development environment. After completing the upgrade to the development environment and executing quality assurance procedures, we promoted the upgraded environment to the production environment.

Phase 1: Upgrade the existing WebLogic Server 8.1SP4 domain using Upgrade Wizard
In this phase we upgraded the existing WebLogic Server 8.1 SP4 domain using the WebLogic Upgrade Wizard that's part of the WebLogic 11g delivery. Initially this was done in our development environment that contained a non-clustered domain. A domain is the basic administration unit for WebLogic Server instances and consists of one or more WebLogic Server instances that can be managed with a single administration server.

The following are the steps involved in upgrading an application environment:

Step 1: Plan the Upgrade

  • Perform inventory on an existing environment
  • Verify support configuration for all hardware and software components
  • Review the compatibility information
  • Create an upgrade plan by identifying the scope and timing of the upgrade process based on the business needs

Step 2: Prepare to Upgrade

  • Un-deploy all applications and shut down all servers
  • Back up the application environment
  • Install a new version of WebLogic Server 11g
  • Copy the WebLogic 8.1 SP4 domain to the WebLogic 11g "domains" directory
  • Set up the environment - Classpath, Path, WebLogic Home, and third-party libraries

Step 3: Upgrade Your Application Environment

  • Upgrade custom security providers: If you are upgrading from WebLogic Server 7.0 or 8.1, and you have custom security providers in your current application environment that you wish to continue using in the new environment, upgrade them on all machines in the environment before you upgrade the WebLogic domain.
  • Upgrade Node Managers: If you are currently using a customized version of Node Manager and you wish to continue doing so in the new application environment, upgrade all the Node Managers on all machines in the environment.
  • Upgrade WebLogic domain (Administration Server): Upgrade the WebLogic domain on the machine that hosts the Administration Server. Note: Oracle recommends that you upgrade Administration Server for a domain before the Managed Servers.
  • Upgrade WebLogic domain (remote Managed Servers): Upgrade the WebLogic domain on every machine that hosts any managed servers. Be sure to copy the appropriate files to the managed servers before performing the upgrade.

Step 4: Complete post-upgrade procedure

  • Re-apply customizations to startup scripts
  • Verify file permissions
  • Enroll the machine with node manager
  • Verify remote server startup options
  • Promote the Application Environment to Production

If any of the above steps fails in the upgrade process, the upgrade wizard terminates and displays a message that notes the reason for the failure. In such cases, restore the application environment to its previous state by using backup files. Correct the failure and continue the upgrade process from the step at which failure is reported.

Issues and Solutions
After upgrading the environment, we were not able to start up the WebLogic server in the new environment. In fact, some manual changes were still required (e.g., changes to the startup scripts).

  • Oracle Type 4 diver is deprecated, i.e., removed in WebLogic 11g version. Instead, it's recommended that you use Oracle Thin driver.
  • The xam library (xam-4.0.jar, a third-party library) had to be upgraded because of differences between JDK 1.4 and 1.6.
  • The deployment plan, plan.xml, is not able to override the non-configurable elements due to parsing issues. Oracle's recommendation is to use the following annotations during parsing: @configurable,@dependency,@declaration,@dynamic.
  • A build and deploy script file for setting environment variables and dependencies should be changed manually.
  • The "pointbase" database section in the "startWebLogic.cmd" file had to be removed because of conflicts with a derby database we used. We replaced this section with commands for setting up our own environment variables, classpaths and paths.
  • The jdbc-xml-file for one of the jdbc-resources defined in config.xml was missing from jdbc config module (DOMAIN_HOME/config/jdbc). This is fixed by adding the path of this file to config.xml
  • In the development environment, in the upgraded "config/config.xml" file, all occurrences of the previous deployment path ".\applications" had to be modified with the new path ".\autodeploy" because of the dev environment. This replacement should be done consistently in all configuration files of the deployed applications.
  • After completion of all the above changes, we could start up our system and run it under WebLogic Server 11g.

Note: We could conduct jUnit tests and Load Runners to make sure that everything worked fine.

Phase 2: Compile, build & application deployment under WebLogic Server 11g
The next phase was to get our build & deployment process under WebLogic Server 11g.The goal was to identify and resolve issues in the process as a preparation for the final upgrade in Phase 3. The compile, build and deployment process supported all stages of setting up the system.

  • Deploy and execute applications in a single server instance or clustered instances in various environment platforms (Windows, Unix)
  • Configure environmental variables WL_HOME and JAVA_HOME and other references to WebLogic 11g and JDK 1.6 installations paths, third-party libraries in various property files and script files used by the build process.
  • Check out all files such as source code, configurations, etc., from our version control repository.
  • Using Ant build script ,compile and build the source code and prepare the .tar file or zip file.
  • Finally the application was deployed into the new WebLogic domain.
  • After the above step, we executed the build process and tried to resolve one problem after another. A majority of the issues were related to the new version of JDK1.6, missing jars and libraries.
  • At the end, we resolved all the JDK-related issues and were able to compile, build, deploy and start our application in the new upgraded environment.

During the upgradation to WebLogic Server 11g, most of the effort was spent on upgrading the build and deployment process. There were only a few modification required to the Java application code.

However, the compile, build and deployment process ran successfully in the development environment only and was not yet completely automated in the production.

Issues and Solutions

  • The WebLogic domain was automatically created using a WebLogic scripting interface of the WebLogic domain configuration wizard. This interface was deprecated in WebLogic Server 11g. Therefore, we created domains manually and postponed solving this issue to final upgradation (Ref Phase 3).
  • Since we have used the JAXB API, we had to add the path to "xbean.jar" to server CLASSPATH.
  • During the deployment process, the WebLogic Server libraries should be available on the classpath to resolve included Java files, and directives/imports in the source code.
  • Make sure the JDBC driver classes are added to the CLASSPATH environment variable.
  • Start the corresponding database
  • In the WebLogic Server 11g environment, in addition to the WebLogic.jar, webserviceclient.jar, ssl.jar, webservices.jar files, we needed a few additional files - weblogic.policy, xbean.jar, WebLogic-container-binding.jar

Phase 3: Post upgradation
In this phase we concentrated on the following activities:

  • Upgrading domain configuration templates by using pack command or by using template builder
  • Automating server configurations and build and deployment processes in all environments.
  • Resolving issues related to Java JDK 1.6.

Automating server configurations and build and deployment processes
The existing environments are configured in different platforms. We have a specific set of configuration, template and scripts for each application environment. Due to the whole server configuration, the build and deployment process could be run automatically without any manual changes.

However, we have discovered the problems with automatic domain generation. Our scripts had to be changed because the configuration wizard interface in silent mode was deprecated in WebLogic Server 11g. Under WebLogic Server 8.1SP4 we used this interface to create a new domain and then to add the JMS and JDBC configurations.

One solution was to use the new WLST (WebLogic Scripting Tool) instead of the domain configuration wizard. Another issue was affected due to the changes to the structure of config.xml in WebLogic Server 11g. Under WebLogic Server 8.1SP4, we used environment-specific templates to generate config.xml files. Accordingly, we had to change these domain templates and we decided to rework the whole creation process completely. It was a good learning opportunity and utilized complete WLST consistently for all administrative tasks.

Resolving Issues Related to WebLogic and JDK 1.6
After the above upgradation steps, we did extensive load and performance tests and under certain situations the transactions were getting timed out; we resolved the issue by changing the transaction time out sufficiently as per the business needs.

Another issue that we found was that the JMS message consumer was not able to connect to the provider. As a result, we had to make application changes to handle the exception handling appropriately.

The final issue was due to the JDK 1.6 version. Client EJB Business components should support both JDK 1.4 and JDK 1.6. Because of this change, we were required to compile the EJB business components in JDK 1.6 version.

Upgradation Estimations
The total upgradation effort required for the upgradation of the application was less than two-person months. The most time-consuming work was Phase 3 (approximately 70% of the effort). Oracle believes that upgradation to WebLogic Server 11g will continue to benefit you over time, offsetting the initial costs of upgradation. However, some benefits will make themselves evident almost immediately.

Next Step - Application Redesign
After upgrading the application, we can consider a redesign of the system in order to take advantage of some new features of WebLogic Server 11g.

In an earlier version of the application, we had written a user-defined timer service for business work flow for notifications. After upgradation we redesigned our application and used the EJB timer service which is added support in WebLogic Server 11g in compliance with EJB 2.1 version. We have found a problem with the timer service in the WebLogic server 11g version because this timer service is not supported in the development mode. We have tested this in the production mode and found no issues.

Summary
This article provides a number of best practices for moving your J2EE applications to WebLogic Server 11g. It describes a few crucial steps and tasks that architects, developers, project managers should be aware of while upgrading to WebLogic Server 11g. During the upgradation process you need to upgrade J2EE application, third-party software/libraries, configurations and the build and deployment scripts to the target environment.

References

  1. Oracle Fusion Middleware
  2. Upgrading WebLogic Application Environments
  3. Creating and Configuring WebLogic Domains Using WLST Offline

More Stories By Sree Kusumanchi

Sree Kusumanchi is lead architect with the Legacy Transformation Group in Satyam Computer Services and has a masters in technology from BITS Pilani.

More Stories By Ramana Urachintala

Ramana Urachintala has a Masters Degree in Computer Science with 12 years of experience in the IT industry. He has experience in the J2EE technologies and has completed four large scale J2EE applications. He has extensive experience in software engineering and technical architecture. As an architect, he guides the development and Middleware team in building the solutions.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.