|By Sree Kusumanchi, Ramana Urachintala||
|December 28, 2010 11:00 AM EST||
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.
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.
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.
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.
May. 4, 2016 07:30 AM EDT Reads: 389
May. 4, 2016 07:00 AM EDT Reads: 814
May. 4, 2016 05:30 AM EDT Reads: 389
May. 4, 2016 05:00 AM EDT Reads: 1,232
May. 4, 2016 04:45 AM EDT Reads: 1,332
May. 4, 2016 03:30 AM EDT Reads: 1,174
May. 3, 2016 11:00 PM EDT Reads: 1,277
May. 3, 2016 10:00 PM EDT Reads: 1,361
May. 3, 2016 09:45 PM EDT Reads: 388
May. 3, 2016 08:45 PM EDT Reads: 1,294
May. 3, 2016 08:30 PM EDT Reads: 1,247
May. 3, 2016 08:00 PM EDT Reads: 1,082
May. 3, 2016 03:15 PM EDT Reads: 1,219
May. 3, 2016 02:30 PM EDT Reads: 971
May. 3, 2016 12:30 PM EDT Reads: 1,199
May. 3, 2016 12:15 PM EDT Reads: 1,598
May. 3, 2016 12:00 PM EDT Reads: 1,378
May. 3, 2016 09:45 AM EDT Reads: 1,479
May. 3, 2016 07:00 AM EDT Reads: 1,151
May. 2, 2016 10:00 AM EDT Reads: 2,709