GlassFish - World's first Java EE 7 Application Server


Migrating the Application

Migrating the application involves the following procedures:

  • Specify Input Java EE Application Details
  • Specify Output Java EE Application Details
  • Migration Actions
  • Automatic Migration Progress
  • Migration Report
  • Using The Toolbar
  • Using the Menu Options

Specify Input Java EE Application Details

In the Input Java EE Application Details panel, you specify:

  1. The Source Application Server for the application to be migrated.
  2. The location and details of the Java EE component or application to be migrated.

Specifying the Source Server

Select the application server from the "Source Server" drop-down list. The migration tool supports, as input sources, the following source platforms:

  • WebLogic Server 5.1/6.0/6.1/8.1
  • WebSphere Application Server 4.0/5.1
  • J2EE Reference Implementation 1.3/1.4
  • Sun ONE Application Server 6.x/7
  • JBoss 3.0 Application Server
  • TomCat 4.1.1.2 WebServer

Specifying the Application Directory or Archive

You can specify input in one of the following forms:

  • A single directory that contains all the source files
  • A single archive file
  • A set of specific file-types in a directory

Select the "Source" radio button to specify multiple archives or a directory as input or select the "Archive" radio button to specify a single archive.

Specifying a Single Archive as Input

To specify a single archive file as input:

  1. Either enter the archive path directly in the "Archive" text field or use the "Browse..." button to navigate to the archive of your choice.
  2. If you select an archive using the "Browse..." button, the archive path will be displayed in the text field.

Specifying a Single Directory as Input

To specify a single directory as input, use one of the following procedures:

  1. Migrate all files in a single directory:

a. To select a single directory containing the source files, either enter the input application path directly in the "Source" text field or use the "Browse..." button to navigate to the directory of your choice.
b. If you select a directory using the "Browse..." button, the directory name will be displayed in the text field.

  1. Migrate specific filetypes in a single directory:

a. If you want to migrate a particular type of file, first select the directory, then use the "Filter..." button. Press the filter button to bring up the "Migrate files of type..." pop-up. Select the file types to migrate. Only files of the file types selected will be migrated from the directory that contains the source files. All other file types will be left as is.
b. If a directory contains multiple archives, you need to select "Archive Files (.jar/.war)" from the "Filter" popup.

If the Migration Tool identifies that you have specified JAR/WAR/RAR files or a single EAR file as input, the tool will create a temporary directory in your home directory. The name of this directory will begin with an "asmt_" prefix and have a "TIMESTAMP" suffix. Another directory, called Input_Archives, will be created in the asmt_TIMESTAMP directory. JAR/WAR/RAR/EAR files will be extracted from the Input_Archives directory. This Input_Archives directory will then be supplied to the Migration Tool as input. If you want to make any changes in the contents of the extracted JAR/WAR/RAR/EAR files, you can directly access these files in the Input_Archives directory. Once you have made the changes, you can resubmit the directory as input to the Migration Tool. You do not need to extract the archives for every change iteration.

Validations Performed

When you press the "Migrate" button, the Migration Tool performs the following validations for the input details:

  1. If you specified a directory as input, the only valid input is a directory that contains one or more Java, JSP, XML, HTM/HTML, JAR, WAR, RAR, or server configuration file(s).
  2. If you specified an archive as input, the only valid input is a single EAR, JAR, WAR, or RAR file.
  3. The Migration Tool does not allow selection of archive (JAR/WAR/RAR/EAR) files and source (HTML, Java, JSP, XML, or configuration) files together. because an archive file needs to be extracted first; source files can be migrated right away.
  4. If the Migration Tool finds JAR files in an EAR file that are not mentioned inside the application.xml file, these JAR files are moved to a directory called Utilities, in the Input_Archives directory.
  5. If the Migration Tool finds that there is insufficient space in the specified output directory to enable successfully extract the archive file, the tool will notify you and abort the extraction process.
  6. Although multiple JAR/WAR/RAR files are allowed as input, you cannot select multiple archives (EAR files) as input.
  7. The Migration Tool iterates through all of the selected files after you press the "Migrate" button. If the tool finds an input file that does not belong to the selected source server in the previous screen, it will prompt you for confirmation about the cross-server input. If you choose to proceed, it will ignore the mismatched file(s). For example, if the input directory/files contains a weblogic.xml file, but the selected source application server is WebSphere Application Server 4.0, pressing the "Migrate" button brings up a dialog box with the following message: 
    "Warning: Found following proprietary file(s) [weblogic.xml] in the
input source code. Source server selected is WebSphere Application server 4.0 whose
proprietary files would be migrated. The artifacts for the other appservers would not be migrated. Do you
want to continue ?"
  8. Empty directories cannot be migrated.

Specify Output Java EE Application Details

You use the "Output Java EE Application Details" panel to specify the destination application server to which the application will be migrated and the output directory to which the Migration Tool will write the migrated source files. The Migration Tool supports only the Sun Java System Application Server as the destination application server. In addition, you can also specify certain advanced migration options.

Specifying the Output Directory

Enter the output directory path directly in the "Directory" text field or press the "Browse" button and locate the directory to which the Migration Tool will write all migrated files.

Specifying the Target Server

The "Target Server" drop-down list shows the target application server to which the Java EE application will be migrated. Your only choice is Sun Java System Application Server. Even though this is your only choice, you still must select it from the drop-down menu.

Specifying Advanced Migration Options

Press the "Advanced" button to display the "Advanced Migration Options" dialog.
This dialog provides the following options:

  • "Migrate CMPs from EJB1.1 to 2.0 specs"

If you select this option, the Migration Tool will try to upgrade the EJB 1.1-compliant CMP entity beans in the input application to the EJB 2.0 CMP specification. The tool accomplishes this using an internal, two-stage process:

In stage one, the Migration Tool verifies that the CMP entity beans in the input source can be upgraded to the EJB 2.0 CMP specification. The tool does not alter the following:

  • The remoteAPI of the bean (consisting of the Remote interface, Home interface, and the Primary Key Class)
  • The business functionality of the bean.

In stage two, the Migration Tool actually upgrades all beans deemed upgradeable in the first stage to EJB 2.0-compliant entity beans. The tool minimally modifies beans that are not upgradeable to make them deployable on the Application Server.
Choosing this option enables the following two options:

  • "Overwrite conflicting accessors"

This "forced migration" option directs the Migration Tool to skip one of the verification steps in stage one. Choosing this option affects the application being migrated. .

  • "Comment out setters of primary key fields"

This "forced migration" option also directs the Migration Tool to skip one of the verification steps in stage one. Choosing this option also affects the application being migrated.

Java2DB Tool Invocation
Enable this option to direct the Migration Tool to generate the output so that you can use the Java2DB tool. If you select this option, you can also:

  • Check the "Create tables at deploy" option to automatically create tables at deployment time.
  • Check the "Delete tables at undeploy" option to automatically delete tables after the application is undeployed.
  • Specify the "Database vendor name." If none is specified, the default (SQL-92) will be used.

With Java2DB support, the application will be successfully deployed in the Application Server when the EJB module (JAR file) contains only an ejb-jar.xml deployment descriptor, sun-ejb-jar.xml deployment descriptor, and CMP bean classes and interfaces.

You can use the generated sun-cmp-mappings deployment descriptor, ddl files, and the file with the database metadata (.dbschema) to change the automatically-generated mappings.

Validations Performed

Press the "Migrate" button and the Migration Tool will perform the following validations for the output details:

  1. Ensure that you specified a valid output directory.
  2. If the directory you specified does not exist, the tool will prompt you to create a new directory (subject to requisite write permissions) or change the specified directory.
  3. If you choose the option to create a new output directory, the Migration Tool will create the output directory.

Note - You cannot create a directory with a name that includes any of the following special characters: asterisk , less than (<), greater than (>), ampersand (&), vbar (|), exclamation , pound sign (#), semicolon (, colon (, white space, open single quotation (`), close single quotation ('), dollar sign ($), or backslash (). However, you can select an existing directory whose name contains these special characters.

  1. Display a warning message if the specified output directory is not empty.
  2. You can synchronously perform multiple migration processes in a single invocation of the Migration Tool. However, the tool will display a warning if you specify the same input and output directories in subsequent sessions.
  3. If you canceled a previous migration session (and used the same output directory), the Migration Tool will display a warning message noting the possibility of overwriting output files.

Migration Actions

The buttons in this area depict various actions that can be peformed once the user has specified all the input and output details.
This area contains four buttons whose functions are as follows:

  • The "Migrate" button starts the actual migration of the application. Before performing the migration, the Migration Tool verifies that the input and output details are valid. The tool performs several validations, described in the sections Specify Input Java EE Application Details and Specify Output Java EE Application Details. After validating the user-supplied input and output details, the Automatic Migration Progress process starts.
  • The "View Report" button allows the user to view the migration report of the open project if that project has been migrated. A detailed Migration Report appears in a separate window. The report contains the status of each file processed by the migration tool. It also contains information about build scripts and other files generated by the migration tool. The full path name for each file is included in the report as an HTML hyperlink. From the Migration Report window, you can click the hyperlink to view the source code of the migrated files. This button is disabled if no migration has been performed or the migration report file of a project has been deleted from the location specified in the project file.
  • The "Reset Fields" button re-initializes the Migration Tool by:
  • Clearing all the text fields
  • Re-initializing all drop-down lists
  • Disabling all Specifying Advanced Migration Options options
  • Disabling the Specifying a Single Directory as Input so the user can migrate another application

You cannot use this button to open a new project for migration.

  • The "Exit" button terminates the Migration Tool. Before quitting, the tool prompts the user to save the opened project file.

Automatic Migration Progress

The Automatic Migration Progress screen displays the migration progress. The screen contains a progress bar that indicates the current activity taking place in the Migration Tool. Apart from the progress bar, a series of check boxes (representing the various constituents of the Java EE application) are checked as the Migration Tool proceeds to migrate the application.
The label-text of the progress bar dynamically indicates the exact stage in the migration progress. The entire migration process goes through these phases:

  • Pre-Processing: Indicates the progress of the pre-processing stage. Once pre-processing is complete, the progress bar re-initializes for the next migration stage. During the pre-processing stage, the tool parses the user input, copies the input directory contents to the output directory, and prepares necessary data-structures.
  • Migrating: The Migrating Input phase is comprised of several stages, one for each category of constituent files:
  • Check-boxes correspond to each stage. These checkboxes are initially shown with a gray background.
  • As the processing for a stage commences, its checkbox is highlighted with a yellow light.
  • After all processing in the stage has finished, its corresponding checkbox is shown as checked (a tick-mark appears).
  • When the set of selected input does not contain a particular type of file, the corresponding stage is skipped and the checkbox remains gray.
  • When the input provided to the migration tool is in the form of directory/file(s), the next-to-last stage is always the creation of an HTML Migration Report. When the input provided is in the form of archive(s) (JAR/WAR/RAR/EAR file(s)) input, the last stage is Building Migrated Output, during which the tool internally executes its dynamically-generated build scripts. This stage is represented by a checkbox as well.

Note - The Building Migrated Output stage is visible only for an archive input. The following screen shows the Automatic Migration screen with this conditional transition.

When the migration finishes, the Migration Tool invokes the automatic JSP Validator.

JSP Validator

The automatic JSP Validator is an engine that validates the tags used in a JSP file, according to the tag libraries that define them. Specifically, this engine checks whether the case of the tags inside the JSP file is different from the case of the tags inside the TLD file. The JSP validator runs this check on the set of JSPs. For any non-conformance it finds, it modifies that tag in the JSP.
Since this is a post-migration activity related to deployment, the current migration report does not include the JSP Validator activity. Instead, a separate XML report is generated for JSP validation. The link for this report is in the Migration Report Table of Contents. The name of the report has the same format as the name of the migration report: for example, JSPValidator_TIMESTAMP.xml. The report is written to the output directory by default. The structure of this report is as follows: 

&lt;validator>
  
       
     &lt;file path="E:\output\iBank\docroot\ShowTransactionHistory.jsp" usesTagLib="true">
        &lt;tld path="/WEB-INF/TMBHisto.tld">
           &lt;tag changed="false">
              &lt;name>printTransactionHistory&lt;/name> 
           &lt;/tag> 
        &lt;/tld> 
     &lt;/file> 
       
     &lt;file path="E:\output\iBank\docroot\TestShowTransactionHistory.jsp" usesTagLib="true">
        &lt;tld path="/WEB-INF/TMBHisto.tld">
           &lt;tag changed="false">
               &lt;name>printTransactionHistory&lt;/name> 
           &lt;/tag> 
        &lt;/tld> 
     &lt;/file> 
       
     &lt;file path="E:\output\iBank\docroot\TransferCheckFailed.jsp" usesTagLib="false"/>
  
       
     &lt;file path="E:\output\iBank\docroot\TransferFunds.jsp" usesTagLib="false"/>
  
  &lt;/validator>

A custom Swing component opens this report, so that the user can expand or collapse all XML nodes.

Interrupting the Migration Process

If you need to interrupt the migration process, press the "Cancel" button located beneath the progress bars. You will be prompted to confirm the action.
The Migration Progress pop-up includes a checkbox that lets you determine the state of the pop-up once the migration terminates. You can choose to automatically close or open the pop-up.

Migration Report

The Migration Tool generates a Migration Report for each migration performed. The report provides insight into the state of the migrated application. It also provides pointers to the next steps that the system administrator performs to successfully deploy the migrated application. View the report by clicking the "View Report" button in the "Actions" panel. The report explains the how and why of the final result of the migration process.

The report is divided into the following logical sections, arranged by order of importance in the overall success of the migration process:

  • The Migration Summary
  • Files That Failed to Migrate
  • Files Partially Migrated
  • Files Changed and Successfully Migrated
  • Files Unchanged and Migrated
  • Build Scripts Generated

The color scheme for each section heading is analogous to a traffic signal color scheme.
There are also links for the following:
JSP Validator
Logging
Post Migration Actions

The Migration Summary

This is a high level view of the migration process, a tabular representation of details about the migration process. An explanation of the contents of this follows.

  • Migration date: 2003-8-6 Time: 4: 31: 43 PM.
  • Source Application Server: J2EE Reference Implementation 1.4
  • Destination Application Server: Sun Java System Application Server Platform Edition 8
  • Input Directory: C:\DOCUME~1\JASPRE~1\LOCALS~1\Temp\asmt_2003_8_6_At_4_31_34_500_PM\Input_Archives
  • Output Directory: >e:\output\j2eeri1.4\hellodb\Input_Archives
  • *Input Archive: E:\work\iasmt3\examples\j2ee_ri_1_4\HelloWorld\HelloWorld.ear
  • *Output Archive Directory: e:\output\j2eeri1.4\hellodb\Input_Archives\build_ear.cmd
    Input Component —> Java JSP XML/XMI HTML Config  
    Failed 0 0 0 0 0  
    Partially Migrated 0 0 0 0 0  
    Successfully Migrated 0 0 4 0 0  
    Unchanged 7 1 0 1 0  
    Total 7 1 4 1 0  
  • This field gets displayed only in the case of archive JAR/WAR/RAR/EAR input.

Files That Failed to Migrate

A list of the files that failed to migrate in the order they were processed by the Migration Tool.

  • Configuration Files These files may fail to migrate if:
  • The selected source server is not applicable for the input configuration file. For example, a weblogic.properties file is encountered when the selected source server is IBM WebSphere 4.0.
  • The configuration file format is incorrect. For example, a server-cfg.xml file includes XML content that is not well formed.
  • XML files XML files may fail to migrate:
  • If the input XML file requires other XML or Java files for migration, and these files are not found in the input directory structure. The migration tool displays the path and name for the required file.
  • Although you can choose an XML file applicable to one application server, the same XML file will cause a differently selected source application server to fail the migration. In this case, the Migration Tool displays the error message for converting the subject XML file, prompting you to select the applicable server as the source application server.
  • The input XML file is not well formed.
  • The input XML file is not valid; that is, it does not conform to its DTD.
  • JSP Files JSP files may fail to migrate because of the following reasons:
  • JSP file migration consists of several independent modifications. The Migration Tool supports most, but not all, of these required modifications. If it detects only unsupported modifications in the input JSP, the migration tool fails migration of that file and lists all such unsupported modifications.

SOLUTION: You should manually edit the output JSP file to achieve migration.

  • In the case of a single JSP file (as input), the file may contain references to the taglibs. The tool fails to migrate such a single JSP file, since it cannot find the corresponding web.xml file for the taglibs (referenced in .jsp file).
  • Java Files Java files may fail to migrate due to:
  • Java file migration consists of several independent modifications. The Migration Tool supports most, but not all, of these required modifications. If it detects only unsupported modifications in the input Java file, the Migration Tool fails migration of that file and lists all such unsupported modifications.

SOLUTION: Manually edit the output Java file to achieve migration.

Files Partially Migrated

Partial migration occurs when the Migration Tool detects some, but not all, the modifications required by the input file for successful migration. The Migration Tool displays a list of all successful, attempted, and failed modifications.
SOLUTION: You can view the non-migrated elements and manually edit the output file to achieve full migration.

  • Configuration Files These files may partially migrate when:
  • The Migration Tool is able to convert some, but not all, of the properties that it supports.
  • JSP Files These files may partially migrate under certain conditions:
  • JSP file migration consists of several independent modifications. The Migration Tool supports most, but not all, of these required modifications. If it detects both supported and unsupported modifications in the input JSP, the Migration Tool performs the supported modifications and lists all the supported and unsupported modifications.

SOLUTION: You can manually edit the output JSP to achieve full migration. An example of a partial migration is:
WebLogic 5.1 is chosen as the source application server and the packages weblogic.servlet.security and weblogic.db.jdbc are present in the JSP file to be migrated. This JSP will be displayed in the 'Files Partially Migrated' section because weblogic.db.jdbc is supported by the Migration Tool and weblogic.servlet.security is not.

  • Java Files

In the case of partial migration, the treatment of Java files is the same as that of JSP files..

Files Changed and Successfully Migrated

This result implies that all the input files were successfully modified by the Migration Tool and are compatible with the destination application server.

  • Configuration Files

Displays files that have the following properties found in the input files and that have been successfully migrated to the target server format.

  • DataSources used by the applications
  • StartupClass properties
  • ThreadPool settings
  • XML files

This section displays files when:

  • The input XML file has been modified and made consistent with the DTD format of the target application server.
  • JSP Files

This section displays files when:

  • All proprietary classes belonging to the source server packages in the input file were successfully modified and made totally compliant with the classes and package structures of the target application server.
  • Java Files

This section displays files when the following apply:

  • Same as those for JSP files.

Files Unchanged and Migrated

If an input file does not require any changes to make it compliant to the target application server, the file is simply copied to the output directory.

  • Configuration Files

Configuration Files
These files may remain unchanged and migrated when:

  • No source server-specific properties are found.
  • XML files

These files may remain unchanged and migrated when:

  • The DTD of the input XML file is compliant with the target application server.
  • JSP Files

These files may remain unchanged and migrated when:

  • No proprietary classes belonging to the source application server are found in the input file.
  • Java Files

These files may remain unchanged and migrated when:

  • No proprietary classes belonging to the source application server are found in the input file.

Build Scripts Generated

After migrating valid input files to the specified destination directory, the Migration Tool generates, for every Java EE component, a corresponding XML file that contains instructions for http://jakarta.apache.org/antto build the corresponding archive file.
In addition to the Ant XML file, the tool generates two scripts, one for Solaris (build_xxx.sh) and another for Windows (build_xxx.cmd). When executed, these scripts invoke Ant. The generated files are as follows:

  • When the DD file is ejb-jar.xml
  • build_jar.xml
  • build_jar.sh
  • build_jar.cmd
  • When the DD file is web.xml
  • build_war.xml
  • build_war.sh
  • build_war.cmd
  • When the DD file is application.xml
  • build_ear.xml
  • build_ear.sh
  • build_ear.cmd
    An optional target deploy, provided in each of the build files, deploys the generated archive file. For example, the build_ear.cmd deploy command generates the EAR file and deploys it on the Application Server.
    A special case occurs when the selected source application server is WebLogic 5.1. Since WebLogic 5.1 has no application.xml file, the migration tool generates a file called application.sasmt. The application.sasmt file is used to generate the EAR file for the target application server.
    The name of the generated JAR, WAR, and EAR files is the same as the display name specified in the corresponding DD file. If the display name is not mentioned, then the first ejb-name and servlet-name are taken to be the JAR and WAR file names respectively. If multiple enterprise beans or Servlets are present in the DD files, "andothers" is concatenated to the file name.
  • If the application.xml file is already present, the names of the generated JAR/WAR files should be the same as the module names specified in the application.xml file.Build Scripts Generated
  • If the application contains multiple JAR and WAR files, then a build.properties file is generated by the Migration Tool in the same directory as the build_ear files.
  • If the display-name tags of the DDs do not have the same name as that of the corresponding module in the application.xml file, you must modify the build.properties file before running the build_ear (.sh or .cmd) file. Such modification of the build.properties file is required because no mapping exists between the module name in the application.xml file and the directory in which the files of that module are present.
  • If the application.xml has either one JAR or one WAR module, then a default one-to-one mapping of JAR/WAR name in the application.xml file and the directory containing the ejb-jar.xml/web.xml file is available. The build.properties file file is not generated in such a case.

The build.properties file consists of properties, which need to be assigned the appropriate module names from the application.xml}}file. A sample {{build.properties file is shown below.

################################################################################
# Modules found in application.xml are
# --->customerEjb.jar&lt;---     
# --->inventoryEjb.jar&lt;---     
# --->petstore.war&lt;---     
################################################################################     
################################################################################     
# Deployment Descriptors have been found in the following directories,    
# please enter a module name from the application.xml that should be given     
# to the module generated from the files inside these directories.     
################################################################################     

# ejb-jar.xml was found in the directory /temp/components/ejb1/src, enter the module name after "=" temp_components_ejb1_src=     

# ejb-jar.xml was found in the directory /temp/components/ejb2/src, enter the module name after "=" temp_components_ejb2_src= 

# web.xml was found in the directory /temp/web/src, the module name     
# has been assigned by the tool from application.xml     

temp_web_src_war=petstore.war

You should assign the appropriate module name to each property, then run the build using the following command:
For Solaris: % sh build_ear.sh -Dp=y
For Windows: PROMPT> build_ear -Dp=y
If you assign incorrect module names to the properties, the generated EAR file is not deployable.

  • If weblogic.properties, config.xml, or server-cfg.xml file is present, the following files are generated:
  • buildconfig.xml
  • buildconfig.sh (for Solaris)
  • buildconfig.cmd (for Windows)
    This build script registers the DataSources and redeploys the StartupClass in the application server.
  • If JMS configuration elements are found inside the config.xml file, the following files are generated:
  • buildjms.xml
  • buildjms.sh (for Solaris)
  • buildjms.cmd (for Windows)
    This build script registers the Destination JMS resources found in the config.xml file.
    For each Connection Factory found inside the config.xml file, two xmls are generated. For example, if the name of the Connection Factory is testConn, the build scripts generated are:
    For registering it as a Queue Connection Factory:
  • buildjmstestConnqf.xml
  • buildjmstestConnqf.sh (for Solaris)
  • buildjmstestConnqf.cmd (for Windows)
    For registering it as a Topic Connection Factory:
  • buildjmstestConntf.xml
  • buildjmstestConntf.sh (for Solaris)
  • buildjmstestConntf.cmd (for Windows)Note -
    Only one of these build scripts should be executed, depending upon the requirement.
    Use the following command for running the configuration build scripts for registering the resources on the application server:
  • On Solaris: % sh filename -Du=<username> -DH=<hostname> -Dp=<portno> -Di=<instancename> -Dw=<passwordfile>
  • On Windows: PROMPT> filename -Du=<username> -DH=<hostname> -Dp=<portno> -Di=<instancename> -Dw=<passwordfile>

Using The Toolbar

The Migration Tool has a toolbar with three icons for frequently performed functions:

  • Press the "New" icon to open a new migration project. If a migration project is already open, you will be prompted to save the open project file. Opening a new project Migration Actions all fields.
  • Press the "Open" icon to open a previously saved project file. If a migration project is already open, you will be prompted to first save the open project file. Then, a dialog box displays from which you select the project file to open.
  • Press the "Save" icon to save the input fields into a project file with a .prj file extension.

Using the Menu Options

The menu bar includes the menu items listed below.

  • Project
  • Edit
  • Help

Project Menu Items

Use the Project menu to do the following:

  • Select "New" to open a new migration project. If a migration project is currently open, you will be prompted to save the opened project file. Opening a new project Using The Toolbar all fields.
  • Select "Open" to open an existing project file. If a migration project is currently open, you will be prompted to save the opened project file and then a dialog box will prompt you to select the project file to open.
  • Select "Save" to save the input fields into a project file (a file with a .prj extension).
  • Select "Save As" to save the project file to a different name or location than the original.
  • Select "Exit" to exit the Migration Tool.

Edit Menu Item

Use the Edit menu to set preferences. If you select the "Preferences" subitem, the Preferences dialog will be displayed. The Preferences dialog has two options: "Logging" and "Miscellaneous."
With the "Logging" option selected, specify your preferences:

  • Under the "Logging" section, select what kind of information will be logged:
  • Tool Migration Log contains information specific to areas of the migration that interest the user.
  • Tool Debugging Log contains debugging information that is generated during migration. This information is useful for tracking the flow of migration from the developers' perspective.

See the Logging section to learn more about the two types of logs.

  • From the "Logging Type" section, specify your preference:
  • Generate either log or generate both logs
  • Append new logging information to an existing log file or overwrite an existing log with new logging information

You should generate both logs in the overwrite mode. Changed preferences take effect after you restart the tool.
With the "Miscellaneous" option selected, specify whether or not to display the Migration Tool's splash screen the next time you start the tool.

Help Menu Items

Use the Help menu to do the following:

  • Select the "User Guide" menu subitem to display online help for using the various Migration Tool functions.
  • Select the "About Migration Tool" to display the Migration Tool's version and copyright information.

Previous Next