Dmitriy Yakubovitch

Subscribe to Dmitriy Yakubovitch: eMailAlertsEmail Alerts
Get Dmitriy Yakubovitch: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java EE Journal

J2EE Journal: Article

J2EE App Migration from WebLogic Server 5.1 to 6.1

J2EE App Migration from BEA WebLogic Server 5.1 to 6.1

Are you planning to upgrade from WebLogic version 5.1 to version 6.1? Do you want to speed up the process of redeploying your EJBs, servlets, and JSPs to a newer version of an application server?

The J2EE specification doesn't define any standard deployment procedures. These differ from vendor to vendor and even from version to version of a particular application server. Read on to find out which steps you should take to redeploy your components and estimate the amount of work to be done.

Migrating and Redeployment
Every J2EE application server allows you to install an EJB if you provide a bean implementation, a remote interface, a home interface, and a deployment descriptor. However, the deployment procedures are vendor-specific and sometimes vary between different versions of the same application server. Everybody wants to move along with the technology and utilize all the new services, that a current J2EE specification provides. It would be beneficial to have standard deployment procedures across all J2EE application servers. Unfortunately, the current EJB specification does not define such policies, so we all have to adjust and follow the guidelines for redeploying our components. This first occurred to me when I was working for a start-up company. We had a solid infrastructure build on top of an application server, but for a number of reasons we had to migrate our system to a newer version of the same application server. I turned my attention to the redeployment issues. In this article I'll concentrate on how to migrate a J2EE application from WebLogic Server 5.1 to 6.1. No programmatic changes need to take place in order to redeploy your components. It's the deployment procedures that differ. There are a number of deployment benefits in WLS 6.1, including deployment formats, consoles for administrating and deploying applications, and EJB and Resource adapter components.

Version 6.1 supports multiple formats for deployment. A J2EE application can be deployed on WebLogic Server either as an Enterprise Application Archive (EAR) file or in an exploded directory format. I shall address the process of migrating and deploying the application as an enterprise application archive further in the article. For now, let me outline high-level procedures in the migration process:

  1. Convert WebLogic license file
  2. Create a new domain in WLS 6.1
  3. Convert to XML files
  4. Modify start/stop script to use new domain
  5. Migrate servlets & JSPs
  6. Migrate EJB applications
  7. Create Web Application Archive (.war)
  8. Create Enterprise Application Archive (.ear)

Now, let's revisit each step and examine it in more detail.

Convert WebLogic License File
The XML-format license file (WebLogicLicense. XML) and the Java-format license file (WebLogic License.class) used in pre-6.0 versions (5.1 or earlier) of WebLogic Server are no longer supported. If a WebLogicLicense.class license file is used in your existing WebLogic Server installation, perform the following tasks before you install WebLogic Server 6.1:

1.   Convert the WebLogicLicense.class license file to a WebLogicLicense.XML file, using the licenseConverter utility provided by BEA at

2.   Convert the WebLogicLicense.XML file as described in "Converting a WebLogicLicense. class License" at

Create New Domain in WebLogic Server 6.1
A new domain must be created. The administration console provides an interface for creating a new domain. WebLogic will create a directory specifically for your domain. Note that the directory structure differs from version 5.1. You should refer to the WLS documentation to get familiar with the directory structure.

Convert to XML files
This step - converting files into XML files - is probably the most important task. The administration console provides a conversion utility to convert a file to appropriate .xml files. It's important to understand what happens behind the scenes. Unlike in WLS 5.1, all the configuration files and deployment descriptors are XML-based. A large weblogic. properties file should be split into a number of XML files. Depending on your application, you may have config.xml, weblogic.xml, web. xml, and application.xml.

Having different kinds of information in a single configuration file makes it impossible to read and tough to maintain. Now, starting with WLS 6.0, all the related information is grouped together in a particular XML file. Your config.xml describes your domain. You should provide a description of the servers in a particular domain, including Listen Ports for connections, SSL-specific information, log file names, security information, and JDBC-related information such as JDBConnectionPool and JDBCData-Source. The description might also include entries for EJB and Web app components, JMS servers, JMS Connec-tion Factories, LDAP realms, custom realms, and so on.

Generally, you shouldn't update this file manually. A configuration console provides an interface to create and update entries in this file. A weblogic.xml file should include WLS-specific attributes, such as jsp-descriptor, security-role-assignment, and a reference-descriptor for a Web application. The deployment information for Web apps should be specified in web.xml. Servlet descriptions, servlet initial parameters, and servlet mappings should be included in this file. The description of your applications, including Web and EJB modules, and additional entries to describe security roles and application resources such as databases should be specified in application.xml. The diagram shown in Figure 1 should assist you in summarizing the described process:

Modify Start/Stop Scripts
The next step, modifying start/stop scripts for a new domain, is fairly straightforward and needs no special attention. There will be default scripts provided by WLS for your domain. You'll need to modify them for your particular environment. You'll have to set some important environment variables, such as WL_HOME, JAVA_HOME, CLASSPATH, and PATH.

Migrate Servlets, JSPs, and EJBs
Create Web and Enterprise Applications

As noted earlier - a J2EE application can be deployed on WebLogic Server as either an Enterprise Application Archive (EAR) file or in exploded directory format. Shown in figure 2, an Enterprise Application Archive file contains all of the .jar and .war component archive files for an application, as well as an XML descriptor that describes the bundled components.

As noted before, the META-INF/application .xml deployment descriptor contains an entry for each Web and EJB module, and additional entries, meant to describe security roles and application resources such as databases. The JAR files are packaged EJBs. The WAR file (Web Application Archive) is organized in a specified directory structure. All servlets, classes, static files, and other resources belonging to a Web Application are organized under a directory hierarchy. The root of this hierarchy defines the document root of the project. All files under this root directory can be served to the client, except for files under the special directory WEB-INF and META-INF, located in the root directory. The diagram in Figure 3 illustrates the directory structure of any Web Application.

The following steps must be performed to package a project as an Enterprise Application file:

1.   Create directory structure for the WAR file and place the Web Application files inside. Follow the directory structure for WAR files above.

2.   Create web.xml file with the description of the Web components.

3.   Package WAR file using a JAR utility.

4.   Copy the WAR and EJB JAR files into the Enterprise Application directory. Follow the directory structure for the EAR file above.

5.   Create a META-INF/application.xml deployment descriptor for the application, using a DTD supplied by Sun Microsystems. The application.xml file contains a descriptor for each component in the application.

6.   Create the Enterprise Archive using a JAR utility.

7.   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 [wls6.1]/config/[your_domain]/ applications directory.

Stateful Session Failover
Although there might be more things to take care of while migrating a particular application, one important thing to note is that the WLS 6.1 EJB container provides clustering support for stateful session beans, whereas in WLS 5.1 only the EJBHome is clustered. Replication support for stateful session EJBs is transparent to clients of the EJB. To replicate the position of a stateful session EJB in a WebLogic Server cluster, ensure that the cluster is consistent with the EJB. In other words, deploy the same bean to every WebLogic Server instance in the cluster, using the same deployment descriptor. Hetero-geneous clusters are not supported for In-memory replication.

By default, WebLogic Server does not replicate the state of stateful session EJB instances in a cluster. To enable replication, set the replication-type deployment parameter to InMemory in the weblogic-ejb-jar.xml deployment file. For example:



At best, the technique discussed in this article facilitates the EJB-migrating of whole applications. At worst, it's a useful pattern to perform the routine aspects of EJB migration. We'll just have to hope that the future EJB specifications will standardize the deployment process to make our applications more portable and vendor-independent.

More Stories By Dmitriy Yakubovitch

Dimitriy Yakubovich has been working with Java and Java-related technologies since they first came out, mostly in the field of distributed computing. He has extensive experience with WebLogic starting with version 4.5 and is cofounder of a successful software company.

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.