Post Migration Actions

During migration, the Migration Tool puts modified files into the output directory you specified. You can manually make additional changes to the generated output to overcome the limitations of the Migration Tool.
You need to complete the following post-migration procedures:

• Interpret the Migration Report, which provides hints about relevant actions you need to take
• Manually Migrate Relevant Configuration Parameters that are listed in the <server-name>ConfigOut.txt file
• Include the DBSCHEMA File/s Inside the JAR file

This step is valid only if the target is the Application Server and the migrated application contains CMP entity beans.

• Building the Migrated Application into a Deployable Unit by using scripts that are generated by the Migration Tool
• Deploying the Built Unit to the Application Server
• Troubleshooting the Building and Deployment Processes

Interpret the Migration Report

The Migration Tool generates a Migration Report for each migration performed. This report provides insight into the state of the migrated application, explaining the "how" and "why" for the migration results. It also provides pointers to the next steps you need to perform to successfully deploy the migrated application. Press the "View Details" button on the Output Result from Automatic Migration screen to display the report. For more details, see the section on the Migration Report.

Manually Migrate Relevant Configuration Parameters

If input to the Migration Tool includes the weblogic.properties, server-cfg.xml, config.xml, resource.properties, regwin.dat, or reg.dat files, the DataSources and StartupClass configuration parameters for WebLogic 5.1/6.0/6.1 will be migrated after you run the Build Scripts Generated.
Your application may use the DataSources registered by the script. To do so, register the database drivers defined in the DataSources with the Application Server. The text file generated by the Migration Tool during compilation provides information for registering the database drivers and other configuration parameters, such as Thread Pool settings. The selected source and target application server determine the name of the text file.

The paths of these files are defined in the Migration Report.

Include the DBSCHEMA File/s Inside the JAR file

Note - This step is required only when the target server for migration is the Application Server and the JAR in question contains a CMP entity bean.
The DBSCHEMA file is an XML file, created by

• Using a utility inside the <AS_HOME>/bin, the DBSCHEMA file captures the database schema of the underlying database tables to which CMP entity beans declared inside the ejb-jar.xml are mapped. The migration generates the sun-cmp-mappings.xml file, which has a tag called "schema" that references the DBSCHEMA file. This schema tag contains the name and location of the DBSCHEMA file, relative to the parent directory of the META-INF directory. The Application Server uses the DBSCHEMA file at deployment time to generate the classes required to persist CMP entity beans.

The schema tag in the sun-cmp-mappings.xml file always contains the name "mySchema". You can replace this value with your DBSCHEMA file name (without the .dbschema extension). Otherwise, you can create the DBSCHEMA file with the name "mySchema".
The following two options are provided for including the DBSCHEMA file inside a JAR:

• Using an environment variable
  Set the DBSCHEMAFP environment variable to the absolute path of the DBSCHEMA file. The referenced schema file is placed inside all the JARs that are created by the build scripts. Use this option only if all the CMP entity beans inside the application use the same database schema. Set the DBSCHEMAFP environment variable before running the build scripts.
  On Windows: set DBSCHEMAFP = c:\mySchemas\mySchema.dbschema
  On Solaris: export DBSCHEMAFP= /usr/schema/mySchema.dbschema
• Copying the file into a particular directory

The DBSCHEMA file can be placed inside the directory that contains the build files that generate the JAR; for example, build_jar.xml, build_jar.cmd, build_jar.sh. When placed as such, the schema file is packaged only inside the JAR.Note -
If both options are used, the created JAR contains both schema files. If the schema files have the same name, the file copied inside the directory is be given priority over the file pointed to by the DBSCHEMAFP environment variable.

Building the Migrated Application into a Deployable Unit

After you read the migration report, make any necessary remedial changes, and configure the Application Server according to the instructions in the <input-specific>ConfigOut.txt file, you can build the application into a deployable unit (JAR, WAR, or EAR file) from the migrated source files. The Migration Tool automatically generates Build Scripts Generated as part of the migration process to automate the build process.
On Solaris, assuming that /migrated_output is the output directory in which the migrated source code is located, complete the following steps to build the migrated application into a deployable unit:
Change directory to /migrated_output.
Set the CLASSPATH environment variable to include all other JAR files or classes that the application code requires to compile.Note -
This is important because it is frequently a failure point when compiling the migrated source code.
Run the generated build script, build_xxx.sh, replacing the xxx with the deployable unit (JAR, WAR, or EAR) you want to be built. For example,

% _sh build_ear.sh_

This initiates the automated build process of the application and creates a deployable unit in the migrated_output/asmtbuild directory.
On Windows, assuming that c:\migrated_output is the output directory in which the migrated source code is located, complete the following steps to build the migrated application into a deployable unit:
Change directory to C:\migrated_output.
Set the CLASSPATH environment variable to include all other JAR files or classes that the application code requires to compile.Note -
This is important because it is frequently a failure point when compiling the migrated source code.
If the deployment descriptors for both the JAR and WAR files are in the same directory, the current directory or a period (".") should not be in the CLASSPATH. This avoids any unnecessary packaging of class files inside the WAR file.
Run the generated build script, build_xxx, replacing the xxx with the deployable unit (JAR, WAR, or EAR) you want to be built. For example,

PROMPT> build_ear

This initiates the automated build process of the application and creates a deployable unit in the C:\migrated_output\asmtbuild directory.

Deploying the Built Unit to the Application Server

After you build the migrated application into a deployable unit, you can deploy it to the Application Server:

• If the input is an EAR, WAR, or JAR file, the Migration Tool will automatically invoke the build scripts once it completes the migration process and places the built EAR file in the <output_directory>/Input_Archives/asmtbuild directory. This EAR will only be built if the migration is successful.

The build may not be automatically created if:

• At least one file fails to migrate
• The Installation and Setup are inadequate.
• On Solaris, where /migrated_output is the output directory in which the migrated source code is located and myunit{{.ear}} is the name of the deployable unit:

Change to the /migrated_output/asmtbuild directory.
Run the asadmin command to deploy the archive:

% asadmin deploy -u <username> --passwordfile <passwordfile> -H <hostname> -p <adminport> myunit.ear

• On Windows, where C:\migrated_output is the output directory in which the migrated source code is located and myunit.ear is the name of the deployable unit:

Change directory to C:\migrated_output\asmtbuild
Run the asadmin command to deploy the archive:

PROMPT> asadmin deploy -u <username>
--passwordfile <passwordfile> -H <hostname>
-p <adminport>
myunit.ear

Note - You can combine the steps to build and deploy the application into a single step by specifying the deploy argument to the generated build script. To use this option, modify the step in which you run the generated build script (Invoking the Migration Tool on Solaris and Linux, Invoking the Migration Tool on Windows) as follows:
On Solaris:

% sh build_ear.sh -Dw=<passwordfile> deploy

On Windows:

PROMPT> build_ear -Dw=<passwordfile> deploy

The build scripts assume the following default values:

• username is "admin"
• hostname is "localhost"
• adminport is "4848"

You can override these default values with the following command:
On Solaris:

% sh build_ear.sh -Du=_<username>_ -DH=_<hostname>_ -Dp=_<portno>_ -Di=_<instancename>_ -Dw=_<passwordfile>_deploy

On Windows:

PROMPT> sh build_ear.sh -Du=_<username>_ -DH=_<hostname>_ -Dp=_<portno>_ -Di=_<instancename>_ -Dw=_<passwordfile>_deploy

If the Migration Tool generated the Migration Report file, you must specify an additional argument, -Dp=y along with the deploy argument.

Troubleshooting the Building and Deployment Processes

Problem: The build script is not generated in the output directory.
Description: The build_xxx script is not in the output directory (where xxx refers to the JAR, WAR, RAR or EAR filename).

• Cause: The deployment descriptor file is not in the input directory.
• Solution: Migrate the deployment descriptor file along with the source Java files and the build scripts will be generated.

• Cause: The deployment descriptor file was not migrated successfully.
• Solution: Fix the deployment descriptor file so that it can be migrated successfully and the build scripts can be generated.

Problem: The build script does not generate the archive file.
Description: Either a "BUILD FAILED" message is displayed or the build was never invoked.

• Cause: The required JAR files are not present in the CLASSPATH, so the source Java files do not get compiled.
• Solution: Modify the CLASSPATH environment variable to include the JAR files that are required for compilation.

• Cause: The directory does not have read/write permissions.
• Solution: Modify the permissions of the directory to have read/write permission.

• Cause: The DBSCHEMA variable is not set for a CMP entity bean present in the JAR file.
• Solution: Set the DBSCHEMA variable to point to the location of the dbschema file.

• Cause: The generated target deployment descriptors contain "REPLACEME" strings.
• Solution: Replace all occurrences of "REPLACEME" with meaningful values.

Problem: The generated archive file does not get deployed.
Description: An exception is thrown when the migrated application is deployed to the Application Server.

• Cause: The application.xml file could contain module names that are not present in the EAR file.
• Solution: Edit the application.xml file so it contains the names of the JAR and WAR files packaged in the EAR file. See the Migration Report section for more information.

Previous Next