Migrating to Pramati Studio

Pramati Studio allows a migration path from other J2EE development environment IDEs and other application server platforms into a new desk or an existing desk in Studio. This chapter describes how to use the Migration tool. Studio provides an integrated full lifecycle solution that allows to migrate applications from different IDEs and application servers, and deployed on other servers. This enables to deliver robust and fast J2EE applications.

How migration works

All J2EE archives and their corresponding sources are used to create a Studio desk. The Migration Tool organizes the sources as per the desk semantics, moves all the EJB components into an EJB module, web components into a web module, and the remaining sources into a Java module. Source package hierarchy is enforced during the process. Migration Tool creates an EJB module for each EJB JAR, a Java module for each utility JAR, and a web module for each WAR containing all the web components. If the WAR contains other supporting classes, a Java module is created and all the sources are stored inside the module.

Pending tasks

Tasks that could not be resolved during migration are displayed as Pending Tasks. These include:

No source file found for a class

CMP queries in the proprietary languages, which can not be converted

Resources to be added to the server

Migration report

A HTML report is generated for each migration in the desk directory. The report provides a summary of the migration and gives a fair estimate of the incomplete tasks, if any. It provides an estimate of non-J2EE and proprietary API usage in the code. It can be accessed via UI in the staging area or in the file system from the location<desk_dir>/Migration.report, where <desk_dir> is the desk root of the target desk. The report consists of:

Desk Structure: This section contains the names of the desk modules that were created per Archive

J2EE Components: Contains information about J2EE components. For example, the number of CMP 2.0, CMP 1.1, BMP, and JSP. This section also contains the number of CMP fields and finder queries. This information may be useful to decide the amount of work needed for OR mapping

Proprietary Package Usage: Contains information about usage of the server specific proprietary API in the code

Pending Tasks: Lists all the tasks to be resolved

Staging

Migration Tool can create a Studio desk in two different modes, with or without staging. Migration with staging allows to customize the desk. Staging gives the user greater control on the structure of the target desk, and also helps resolve the pending tasks with the appropriate UI. For example, tracing missing sources or writing queries. When a module is moved from the staging area to the destination desk, the required meta-data is also moved, transparently. When files are moved individually, the corresponding meta-data files should be moved separately. For example, moving the ejb-jar.xml in EJB module. To know more about working with Staging, read the section `Starting Migration'.

Types of migration

Generic Migration

Create the desk using J2EE and utility archives and their corresponding sources. This desk contains the packaging information, and does not contain any deployment information.

Select Tools > Deploy from the main menu to deploy the desk using Deploy Tool. Complete all information required for deployment. All deployment information is entered in Studio, and Migration Tool can be used to migrate sources and archives from all J2EE environments.

Specific application server migration

The desk is created using the packaged archives and deployable archives from other servers with package and deployment time information. The desk created in this case, is always in a "ready-to-deploy" state and can be deployed using the Express Development feature.

The Migration tool supports specific application server migration' of packaged archives and deployable archives from the following application servers:

BEA WebLogic 5.1

BEA WebLogic 6.1

Sun Reference Implementation 1.2

Configuring Migration Tool

To migrate applications from different J2EE environments and other application server platforms, and then develop the same with additional features in Studio, the Migration tool needs to be configured in Studio. Click on Tools > Configure from the main menu. In the Tools Configure dialog that comes up, check against the option - Migrate, and close the dialog box. This brings up the Migration tool in Studio menu bar.

Starting Migration

To bring up the Migration tool, select Tools > Migration from the main menu. When the Migration tool comes up, enter the following information to start migrating:

The first panel that comes up comprises two sections: - Migrate From and Migrate To.

Migrate From Select the type of migration to be used in this section. The list shows all the supported types of migration. To migrate to a Pramati Studio 3.0 desk without the deployment information, select the Generic Archives. The deploy tool can then be used to complete the deployment Information.

To migrate from one of the listed application servers, select the specific server. Migrating in this case contains all the deployment information.

Migrate To This section comprises all the information about the target desk and information about the migration process.

Select from the two options Create New Desk and Use Existing Desk to decide the target desk.

Name Selecting Create New Desk allows the name of the desk to be entered in this field. Selecting the option Use Existing Desk displays a list of all the open desks in Studio.

Directory This option is enabled only when the option Create New Desk is selected. Browse and select the location to store the desk.

Use Staging Check this option to use staging in the migration process. The Staging option facilitates the users to customize the desk structure created. Using this option shows the discovered desk to the user in a separate panel called the Staging Area, and the target desk in Studio.

When the Staging Area comes up, the user can choose the modules or files required in the target desk and customize the target desk. It gives the user the freedom to merge the content of two or more modules into one module, or create multiple modules using the content of a single module. Migrating into Pramati Studio 3.0 desk after unchecking the option Use Staging, converts the discovered desk into the target desk directly. Click Next after filling all the information in the panel.

The second panel that comes up requires all the archives and/or the source directories to be selected for migration. The source directories contain all the sources for the archives selected. The checkbox is selected when all the sources not corresponding to classes in the archives are to be migrated. These migrated source files are then stored in a Java module called "RemainingSources". These sources may be the sources corresponding to the clients or test cases. Click Next after entering all the archives and source directories.

The third panel that comes up displays the migration progress. To cancel migration at any stage, click Cancel. During migration, if multiple sources are found for a single class, the user is prompted for the right file.

After the migration process is complete, the Staging Area comes up, if the option Use Staging was checked in the first panel. If the Use Staging option was unchecked in the first panel, the Staging Area does not come up and the target desk is created automatically in Studio.

The Staging Area that comes up resizes Studio to fit in the screen. The Staging Area shows the discovered desk and a set of pending tasks. The target desk is displayed in Studio. To move modules/files from the discovered desk to the target desk, select one or more files in the Staging Area, and a single node in the target desk, and click the forward arrow button. This moves the selected files from the discovered desk to the target desk. Modules can also be moved target desk using this button. To undo and redo the tasks, use the Undo and Redo buttons in the Staging Area. To move the entire desk from the discovered desk to the target desk, select the desk root node in the Staging Area and click the forward arrow icon.

Resolving Pending Tasks

All the pending tasks that could not be automatically resolved during migration are displayed in the Pending Tasks area. To resolve the pending tasks, double click on the pending task in the Pending Tasks list. A dialog comes up, that can be used to resolve the task. For example if the pending task is a missing file, then the file chooser dialog box pops up, which can be used to select the file. After the task has been resolved, it is removed from the Pending Tasks list and the Generated Migration Report.

Staging Restrictions

In order to maintain the desk semantics, there are some restrictions in moving file(s)/folder(s) to the target desk from Staging Area:

If a module is moved to a target desk, then irrespective of the target node selected the module always is moved to Desk Root node.

If the target node is the Desk Root node and the selected node in the Staging Area is not a module, then the move is invalid and the selected nodes are not moved to the target desk.

If the node selected in the target desk is a file node, then the selected items are moved to the to its immediate parent node (which could be a normal folder or module).

Making the Migrated desk "Ready-to-be-Deployed"

Add the resources using the Resources Tool, only in case Staging was not used to migrate. Using the Staging option to migrate, displays this as a pending task.

Change the sources to remove the Proprietary API usages, if any.

Add the required classpaths.

Compile all the files using Clean Build.

Use Bean Properties panel to modify and complete the packaging and deployment information.

WebLogic 6.1 Migration Restrictions

Some points to be kept in mind, while migrating source files from WebLogic 6.1 are:

Studio does not expose the local JNDI names of the beans. It takes the LOCAL JNDI name to be JNDIName_local. Therefore, while migrating WebLogic 6.1 sources, the JNDI names if present are made the JNDI name of the bean.

If JNDI name is not present, then the local JNDI name is used as the JNDI name. When the code uses the local JNDI name, sources are to be changed accordingly.

The information about the Third Party JMS Server used is not extracted during migration. It must be configured in the server configuration for each server.