Migration from IBM WAS 7.0 to WAS 8

Here is a small guide, I wrote a few years back for the WebSphere User Group about WAS 7 migration. If you’re looking for advice on how to migrate to WAS 8, WAS 8.5, or WAS 8.5.5 then feel free to contact me via my support site.

Introduction

IBM WebSphere Application Server version 8 (WAS 8) has been around for a while now and so organizations are now evaluating migration of their application servers and applications. In this article we are going to focus on using IBM supplied tools to help with migration of a WAS profile from WAS 7 to WAS 8. We will also cover migration of an application or suite of applications from WAS 7 to WAS 8.

Application server vendors like IBM upgrade their software such as WebSphere Application Server to be in sync with the latest JEE specification. The following table shows the fundamental difference in specification levels between WAS 7.0 and 8.0.

Specification WAS 7.0 WAS 8.0
JEE 5.0 6.0
EJB 3.0 3.1
Servlet 2.5 3.0
JSP 2.1 2.2

The drivers for migration usually are

  • Old version of application server product going out of support
  • Availability of new capabilities and improved performance levels of the newer version of product as supported by the JEE APIs implemented in a given release of WAS.

For some organizations their applications may not require any specific changes, however for other this could be huge project involving many application dependencies all depending on the JEE frameworks used in application design. Not only does their need to be consideration for migrating application servers, but there is a clear need to migrate applications as well. Though related, the migration of application servers and applications may not be part of the same project deliverable. An important point to note is application migration requires careful consideration.

Application migration is a huge and complex area due to many reasons. JEE has grown into a very vast set of application programming interfaces. JEE specification is upgraded continuously and with each release.

  • New API’s, classes and methods are added to satisfy ever growing needs
  • Some API’s, classes and methods are deprecated
  • Some API’s, classes and methods are removed following deprecation in earlier releases
  • Changes in behavior of some of the methods

As part of the application migration process, one might also want to migrate the application’s supprintg databases, administration/deployment scripts, move to newer hardware and operating system etc. If the JEE application uses vendor specific classes, then migration from one application server to another is even more challenging. Even within WebSphere application server, migration of complex topologies that involves Job Manager and Deployment managers needs to be planned and executed carefully.

Note: Many organizations are skipping migration of WAS 6.1 to WAS 7 and are instead going straight to WAS 8. This is quite a jump and the intricacies are many, to much for succinct article on a WAS 6.1 to WAS 8 migration.

Migration tools

IBM provides several tools to make migration from an earlier version as smooth as possible. WAS v8.0 migration tools support the migration from WAS v6.0, v6.1 and v7.0. The following diagram explains the application of these tools.

There are many things to be migrated, but the most important things are

  1. Migration of application server configuration (profile)
  2. Migration of applications

 

 

 

The Migration wizard is a GUI based tool, just like the profile management tool. It internally uses the same set of programs used by WASPreUpgrade.sh and WASPostUpgrade.sh, which are command line scripts. To perform the migration of application server configuration in silent mode, one can use the command line scripts WASPreUpgrade.sh and WASPostUpgrade.sh.

The Application migration tool is available as eclipse feature and can be installed into eclipse version 3.5 or higher. This toolkit can also be installed in Rational Application Developer version 7.5 to 8.5. This tool is a rule based code analyzer and when run against an eclipse project, can identify issues that can impact migration of the application to the newer version of WAS. The tool also can automatically fix certain types of issues. With the help of this tool, one case migrate applications to the newer JEE specification very quickly.

The migration wizard can also deploy the applications as it is in the new application server, but this may not work in many cases.

Migrating standalone application server

WebSphere Application Server supports the following topologies

  • Standalone application server
  • Administrative agent topology
  • Network Deployment topology
  • Job Manager topology

As an example, let us migrate a standalone application server profile called “appsrv03” that hosts a single application called EStore. This application is a simple test application that uses derby database.

This is the simplest case possible, but definitely helps us to understand the migration process. Once this is done, one can plan for complex migration scenarios involving other types of topologies with ease.

During the migration, based on your requirements, you might want to reuse the port numbers used by the older profile. The migration tool helps in this aspect as well.

Configuration migration is a three step process as shown in the diagram.

  1. Execute WASPreUpgrade.sh tool and create backup directory
  2. Create a new target profile using PMT/manageprofiles.sh
  3. Execute WASPostUpgrade.sh tool and complete migration
  4. Executing WASPreUpgrade.sh

The WASPreUpgrade.sh script copies the configuration of WAS 7.0 version of appsrv03 profile to a directory. This backup can then be utilized by WASPostUpgrade.sh script to complete the migration. Note that this backup is not the same as the one created by backupConfig command. This backup mainly acts as the staging directory for migration and is tailor made for migration. Remember to execute these scripts from <WAS_ROOT>/bin directory of WAS 8.0.

Creation of the new WAS 8.0 profile can be done any time before running WASPostUpgrade.sh script, though I have mentioned the profile creation as the second step.

Note that the WAS 7.0 version of appsrv03 (old profile) is not touched during the migration, so it is possible to roll back to the old version at any point in time, if you face any issue.

 

[wasadmin@localhost bin]$ ./WASPreUpgrade.sh /opt/software/was7to8/appsrv03_backup /opt/IBM/WebSphere/WAS7ND -oldProfile appsrv03

IBM WebSphere Application Server, Release 8.0

Product Upgrade PreUpgrade tool, Version 1.0

Copyright IBM Corp., 1997-2010

 

MIGR0300I: The migration function is starting to save the existing Application Server environment.

MIGR0302I: The existing files are being saved.

MIGR0385I: Starting to save profile appsrv03.

MIGR0303I: The existing Application Server environment is saved.

MIGR0420I: The first step of migration completed successfully.

[wasadmin@localhost bin]$

 

The following parameters are passed in this example

  • backupDirectory – directory where the tool stores the configuration
  • Installation directory of WAS 7.0
  • Profile name

Another parameter called “-machineChange=true” can be included if the target profile (WAS 8.0 version of appsrv03) is to reside in a different machine. This parameter forces WASPreUpgrade.sh to copy files that reside outside WAS product and profile directories to the backup directory. These files are then restored to the original location in the new machine by WASPostUpgrade.sh tool.

Let us inspect the files created in the backup directory.

 

[wasadmin@localhost appsrv03_backup]$ ls -l

drwxr-xr-x. 2 wasadmin wasgroup 4096 Aug 4 17:01 logs

-rw-r–r–. 1 wasadmin wasgroup 211 Aug 4 16:58 PreUpgradeInfo.props

drwxr-xr-x. 3 wasadmin wasgroup 4096 Aug 4 16:58 profiles

drwxr-xr-x. 5 wasadmin wasgroup 4096 Aug 4 16:58 websphere_backup

-rw-r–r–. 1 wasadmin wasgroup 217 Aug 4 16:58 websphere_backup_cmd_line_args.ser

The tool creates a directory called logs and writes the log messages related to the migration within this folder. This can be used for troubleshooting purposes.

The tool writes the command that was issued in the log file. This serves as a record and helps in troubleshooting. The first few lines of the WASPreUpgrade.<profileName>.<timestamp>.log file is shown below.

[wasadmin@localhost logs]$ head -10 WASPreUpgrade.appsrv03.Sat-Aug-04-16.58.29-2012.log

[08/04/2012 16:58:29:252 IST] MIGR0201I: The migration function initialized log file WASPreUpgrade.appsrv03.log.

[08/04/2012 16:58:29:253 IST] Given command: “WASPreUpgrade /opt/software/was7to8/appsrv03_backup /opt/IBM/WebSphere/WAS7ND -oldProfile appsrv03”

[08/04/2012 16:58:29:259 IST] MIGR0300I: The migration function is starting to save the existing Application Server environment.

[08/04/2012 16:58:29:262 IST] MIGR0302I: The existing files are being saved.

[08/04/2012 16:58:30:130 IST] MIGR0385I: Starting to save profile appsrv03.

[08/04/2012 16:58:30:798 IST] MIGR0000I: Workspace root folder for profile appsrv03 – wstemp.

[08/04/2012 16:58:40:950 IST] MIGR0344I: Processing configuration file /opt/IBM/WebSphere/WAS7ND/properties/uddi4j.properties.

[08/04/2012 16:58:40:951 IST] MIGR0344I: Processing configuration file /opt/IBM/WebSphere/WAS7ND/properties/jmx.properties.

[08/04/2012 16:58:40:952 IST] MIGR0344I: Processing configuration file /opt/IBM/WebSphere/WAS7ND/properties/dfltbndngs.dtd.

[08/04/2012 16:58:40:953 IST] MIGR0344I: Processing configuration file /opt/IBM/WebSphere/WAS7ND/properties/wsadmin.properties.

The file PreUpgradeInfo.props also captures the arguments passed toWASPreUpgrade.sh. The content of this file is shown below.

 

[wasadmin@localhost appsrv03_backup]$ cat PreUpgradeInfo.props

#Saved OS info and PreUpgrade args for cross OS migration

#Sat Aug 04 16:58:45 IST 2012

args3=appsrv03

args2=-oldProfile

os.name=Linux

args1=/opt/IBM/WebSphere/WAS7ND

args0=/opt/software/was7to8/appsrv03_backup

 

  1. Create a WAS 8.0 standalone application server profile

The creation of WAS 8.0 profile that should serve as the target for migration has to be done manually. The migration tools will not do this. So let us create a new WAS 8.0 standalone application server profile using PMT.

When you come to Port Values Assignment screen while using the profile creation wizard you need not worry about assigning the same ports as the WAS 7.0 version of appsrv03 profile. Accept the default values and proceed. Later on when we use WASPostUpgrade.sh tool, we can select to use ports from the source profile.


  1. Executing WASPostUpgrade.sh command

We completed the creation of a new WAS 8.0 standalone application server profile. Now let us run WASPostUpgrade.sh command. This command supports “-replacePorts true” option which maps the ports from the source to the target profile. When there is a port conflict, WASPostUpgrade.sh tool automatically uses the next higher port value. It is also possible to provide a base port number with the help of “-portBlock” parameter for the allocation of new ports. If you do that, any new port numbers assigned will start from the base port number.

The “–includeApps true” parameter forces the tool to install user applications also. Due to this we expect EStoreApplication.ear to be automatically installed in the target profile when we execute WASPostUpgrade.sh.

The sample applications are always ignored by WASPostUpgrade.sh tool and are not migrated.

 

[wasadmin@localhost bin]$ ./WASPostUpgrade.sh /opt/software/was7to8/appsrv03_backup -oldProfile appsrv03 -profileName appsrv03 -replacePorts true -includeApps true

IBM WebSphere Application Server, Release 8.0

Product Upgrade PostUpgrade tool, Version 1.0

Copyright IBM Corp., 1997-2010

 

MIGR0304I: The previous WebSphere environment is being merged into this profile.

MIGR0367I: Backing up the current Application Server environment.

MIGR0524I: The migration function cannot create the destination file /opt/IBM/WebSphere/AppServer/java/jre/lib/security/java.security.premigration. It already existed. The source file /opt/IBM/WebSphere/AppServer/java/jre/lib/security/java.security cannot be migrated.

MIGR0434I: Will not be migrating object query.ear of type Ear File, it is already installed.

MIGR0251I: The migration does not include object DefaultApplication.ear of type Ear File; it is a Sample.

MIGR0251I: The migration does not include object ivtApp.ear of type Ear File; it is a Sample.

MIGR0251I: The migration does not include object PlantsByWebSphere.ear of type Ear File; it is a Sample.

MIGR0251I: The migration does not include object SamplesGallery.ear of type Ear File; it is a Sample.

CEIMI0006I Starting the migration of Common Event Infrastructure.

CWPST9006W: The application server did not migrate the defaultBindings.xml default bindings file because the file exists in the new system.

CWPST9004W: The application server did not migrate the Provider sample binding because a binding with the same name exists in the new system.

CWPST9004W: The application server did not migrate the Client sample binding because a binding with the same name exists in the new system.

MIGR0229I: The migration function is updating the attributes of SSLConfig entry NodeDefaultSSLSettings. This entry is already defined in the existing model.

MIGR0486I: The Transports setting in file server.xml is deprecated.

MIGR0486I: The PMIService:initialSpecLevel setting in file server.xml is deprecated.

MIGR0339I: Application commsvc.ear is deploying using the wsadmin command.

MIGR0499I: Application commsvc.ear successfully deployed using the wsadmin command.

MIGR0339I: Application EStoreApplication.ear is deploying using the wsadmin command.

MIGR0499I: Application EStoreApplication.ear successfully deployed using the wsadmin command.

CEIMI0007I The Common Event Infrastructure migration is complete.

MIGR0307I: The restoration of the previous Application Server environment is complete.

MIGR0271W: Migration completed successfully, with one or more warnings.

[wasadmin@localhost bin]$

 

Ok, now the migration is completed. Let us run the Jython script called printWasPorts() to obtain the port numbers of the target profile. The ports listing of the target profile shows that they are modified by WASPostUpgrade.sh script and now match the ports in the source profile. The various columns present here are profile name, node name, server name, port number and port name.

 

appsrv03 localhostNode01 server1 2813 BOOTSTRAP_ADDRESS

appsrv03 localhostNode01 server1 8886 SOAP_CONNECTOR_ADDRESS

appsrv03 localhostNode01 server1 9106 ORB_LISTENER_ADDRESS

appsrv03 localhostNode01 server1 9421 SAS_SSL_SERVERAUTH_LISTENER_ADDRESS

appsrv03 localhostNode01 server1 9420 CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS

appsrv03 localhostNode01 server1 9419 CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS

appsrv03 localhostNode01 server1 9066 WC_adminhost

appsrv03 localhostNode01 server1 9084 WC_defaulthost

appsrv03 localhostNode01 server1 9360 DCS_UNICAST_ADDRESS

appsrv03 localhostNode01 server1 9049 WC_adminhost_secure

appsrv03 localhostNode01 server1 9447 WC_defaulthost_secure

appsrv03 localhostNode01 server1 5069 SIP_DEFAULTHOST

appsrv03 localhostNode01 server1 5068 SIP_DEFAULTHOST_SECURE

appsrv03 localhostNode01 server1 7282 SIB_ENDPOINT_ADDRESS

appsrv03 localhostNode01 server1 7290 SIB_ENDPOINT_SECURE_ADDRESS

appsrv03 localhostNode01 server1 5562 SIB_MQ_ENDPOINT_ADDRESS

appsrv03 localhostNode01 server1 5582 SIB_MQ_ENDPOINT_SECURE_ADDRESS

appsrv03 localhostNode01 server1 9638 IPC_CONNECTOR_ADDRESS

 

You can refer to my previous article here, if you want know about “printWasPorts()” Jython script. I created this script and use this script quite often.

 

Let’s now check whether WASPostUpgrade.sh has created the necessary resources in the target profile.

Let me shutdown the server in the source profile. I need to do this as both the source and target servers share the same port numbers. The server in the target profile is started.

The screen shot shows that the JDBC provider is created by the migration tool.

The next screen shot shows the data source created by the tool.

Next, we check the application.

 

The test application EStoreApplication works fine after the migration. Well, the test application is a very simple web application and hence worked as expected without any code modification. We will discuss application migration later.

Installing applications separately

We used “-includeApps true” option when we executed WASPostUpgrade.sh. It is possible to avoid the installation of applications, but create installation scripts instead using “-includeApps script” option.

To give you an example,

 

[wasadmin@localhost bin]$ ./WASPostUpgrade.sh /opt/software/was7to8/appsrv03_backup -oldProfile appsrv03 -profileName appsrv03 -replacePorts true -includeApps script

IBM WebSphere Application Server, Release 8.0

Product Upgrade PostUpgrade tool, Version 1.0

Copyright IBM Corp., 1997-2010

 

MIGR0304I: The previous WebSphere environment is being merged into this profile.

MIGR0367I: Backing up the current Application Server environment.

MIGR0524I: The migration function cannot create the destination file /opt/IBM/WebSphere/AppServer/java/jre/lib/security/java.security.premigration. It already existed. The source file /opt/IBM/WebSphere/AppServer/java/jre/lib/security/java.security cannot be migrated.

MIGR0434I: Will not be migrating object query.ear of type Ear File, it is already installed.

MIGR0251I: The migration does not include object DefaultApplication.ear of type Ear File; it is a Sample.

MIGR0251I: The migration does not include object ivtApp.ear of type Ear File; it is a Sample.

MIGR0251I: The migration does not include object PlantsByWebSphere.ear of type Ear File; it is a Sample.

MIGR0251I: The migration does not include object SamplesGallery.ear of type Ear File; it is a Sample.

CEIMI0006I Starting the migration of Common Event Infrastructure.

CWPST9006W: The application server did not migrate the defaultBindings.xml default bindings file because the file exists in the new system.

CWPST9004W: The application server did not migrate the Provider sample binding because a binding with the same name exists in the new system.

CWPST9004W: The application server did not migrate the Client sample binding because a binding with the same name exists in the new system.

MIGR0229I: The migration function is updating the attributes of SSLConfig entry NodeDefaultSSLSettings. This entry is already defined in the existing model.

MIGR0486I: The Transports setting in file server.xml is deprecated.

MIGR0486I: The PMIService:initialSpecLevel setting in file server.xml is deprecated.

CEIMI0007I The Common Event Infrastructure migration is complete.

MIGR0307I: The restoration of the previous Application Server environment is complete.

MIGR0271W: Migration completed successfully, with one or more warnings.

 

Though applications are not installed, the resources like JDBC Providers and Data sources are migrated to the target profile. The EAR files of the source profile is copied to <profile_v8.0_root>/installableApps directory. In addition to this, Jython scripts are created under migration staging directory (backup directory) as shown in the screenshot and these scripts can be used to install the applications.

To install the application,

  • Cd to <profile_v8.0_root>/bin directory
  • Simply run the install_<app_name>.ear.jy script as shown below.
 

[wasadmin@localhost bin]$ ./wsadmin.sh -conntype none -f /opt/software/was7to8/appsrv03_backup/install_EStoreApplication.ear.jy -lang jython

WASX7357I: By request, this scripting client is not connected to any server process. Certain configuration and application operations will be available in local mode.

ADMA5016I: Installation of EStoreApplication started.

ADMA5058I: Application and module versions are validated with versions of deployment targets.

ADMA5005I: The application EStoreApplication is configured in the WebSphere Application Server repository.

ADMA5005I: The application EStoreApplication is configured in the WebSphere Application Server repository.

ADMA5081I: The bootstrap address for client module is configured in the WebSphere Application Server repository.

ADMA5053I: The library references for the installed optional package are created.

ADMA5005I: The application EStoreApplication is configured in the WebSphere Application Server repository.

ADMA5001I: The application binaries are saved in /opt/IBM/WebSphere/AppServer/profiles/appsrv03/wstemp/Script139013661c5/workspace/cells/localhostNode04Cell/applications/EStoreApplication.ear/EStoreApplication.ear

ADMA5005I: The application EStoreApplication is configured in the WebSphere Application Server repository.

SECJ0400I: Successfully updated the application EStoreApplication with the appContextIDForSecurity information.

ADMA5005I: The application EStoreApplication is configured in the WebSphere Application Server repository.

ADMA5005I: The application EStoreApplication is configured in the WebSphere Application Server repository.

ADMA5113I: Activation plan created successfully.

ADMA5011I: The cleanup of the temp directory for application EStoreApplication is complete.

ADMA5013I: Application EStoreApplication installed successfully.

 

The application is not started by default by this script. Start the application after installation.

Migration using the wizard

Instead of using the command line tools WASPreUpgrade.sh and WASPostUpgrade.sh, it is possible to complete the migration using the migration wizard which works in GUI mode. The migration wizard can be triggered by executing migration.sh script available under <WAS_8.0_ROOT>/bin folder.

[wasadmin@localhost bin]$ ./migration.sh

A screen similar to the one shown below is displayed. We just proceed by clicking New button.

If the migration wizard could not locate the earlier version of WAS, you can provide the installation location. In this example it automatically detected WAS 7.0 installation.

We click Next button to proceed.

At this point, the migration wizard collects information required to take a backup of the source profile’s configuration. We select “appsrv03” as the source profile and accept the default location for the backup directory. The wizard will use the backupConfig command to take a backup. Note that the purpose of this directory is different from the one created for migration.

We click Next button to proceed.

 

Next we provide the directory that should serve as staging directory (or migration backup directory) for migration. The wizard also allows you to select the logs folder where log messages related to migration will be written. The trace level to be used by WASPreUpgrade.sh and WASPostUpgrade.sh can also be selected in this screen.

We click Next to button proceed.

If you have not created a target profile, you can ask the migration wizard to create the target profile. In our case we have already created the target profile using PMT and hence we just proceed by selecting the target profile from the list. Note that the target profile name can be the same as the source profile name. (This is because every version of WAS maintains its own profile registry. Also profiles belonging to different versions of WAS can co-exist without issues.)

Optionally we can take a backup of the existing target profile’s configuration.

We proceed by clicking Next button.

Though in this example we choose to migrate and install the applications, this is not be the right approach for huge JEE applications (actually depends on whether the JEE API’s used changed or not). Applications need to be migrated separately using the application migration tool. The migration wizard makes the job easier for us in that case, by creating scripts to install the application. These scripts can be used to install the application once we complete application migration.

We proceed by clicking Next button.

Here we can control the port values that are to be assigned to the target profile. If we want to reuse the port numbers in the source profile, we can also influence the way the migration wizard handles port conflicts.

By default, the migration wizard increments the port number and tries again when it encounters a port number conflict.

We proceed by clicking Next button.

 

By selecting “Migrate object types to support script compatibility” we ask the migration tool to bring the security configuration from WAS 7.0 profile to WAS 8.0 profile. This means that the private keys and digital certificates will be copied from the source profile to the target profile. If this option is not selected, the default security configuration of WAS 8.0 profile is used. Also the old administration scripts might run without any changes when we use this option.

The convertScriptCompatibility.sh script from <profile_v8.0_root>/bin can be run later after the migration to convert the configuration of the profile from a mode that provides backward compatibility of administration scripts to a mode that is only WAS 8.0 compatible.

We proceed by clicking Next button.

We review the summary information and then we click Migrate button to proceed.

As the migration progresses, green tick marks appear in various tabs. We can also see the progress information in the text area.

When migration completes, the wizard provides the path of the log files. These log files can be used for troubleshooting purposes. We click Finish button.

Now we can see that the migration status is “Success” under Migration Sources tab.

 

The Migration Summary tab has some useful information. It shows the commands executed by the migration wizard. Note that it provides the complete command with all the options used.

 

We just saw how we can use the migration wizard to migrate server configuration from older version of WAS to WAS 8.0 in GUI mode. The migration wizard may not be the right tool for production environments without GUI capabilities. Also the migration wizard uses tools like WASPreUpgrade.sh to do its work and we saw that these tools are directly accessible for administrators to perform migration in silent mode.

Application Migration

Application migration is done to make the application work in the same way in the newer version of application server as in the older version. What this means is, the process of migration is not complete without testing the migrated code. It is very important to prove that the migrated code works as expected in the newer version of application server.

  1. Installing application migration toolkit in Eclipse IDE

You can download the application migration toolkit from

http://www.ibm.com/developerworks/websphere/downloads/migtoolkit/vtov.html

The application migration toolkit is provided as an eclipse feature as mention earlier. To install the toolkit, you can follow the steps given here.

  • Start Eclipse IDE
  • Select Install New Software menu-item from Help menu

  • Click Add button

  • Enter “Application Migration Tool – WebSphere Version to Version” in the Name field
  • Enter the location of the file “Application_Migration_Tool_WeSphere_Version_to_Version_v3.5.0.zip” that you downloaded
  • Click OK button

  • Select the tools
  • Make sure the option “Contact all update sites during install to find required software” is checked
  • Click Next button

  • Review the items to be installed
  • Click Next button

  • Read and accept the license agreement
  • Click Finish button

The time required to complete installation depends on your internet connection speed.

  • Wait for a few minutes

 

Once the installation completes, Eclipse prompts you to restart the Eclipse IDE.

  1. Configuring Eclipse IDE for code analysis

Before we start analyzing code, we need to add a Java EE runtime library in Eclipse. This is because we need the JEE libraries to compile the project successfully. WAS 8.0 comes with runtime libraries starting from JEE 1.3 as shown below.

To migrate to WAS 8.0, we need to use the one under <WAS_8.0_ROOT>/dev/JavaEE/6.0. You can follow the steps outlined here to configure Java EE runtime library.

  1. Click Preferences menu-item under Window menu in Eclipse IDE
  2. Drill down to Runtime environments under Server
  3. Click Add button
  4. Choose Basic | J2EE runtime library and click Next button
  5. Give a name, say JEE 6.0 runtime library
  6. Click browse button and select “<WAS_ROOT>/dev/JavaEE/6.0” folder
  7. Click Finish button

  1. Import the application into Eclipse IDE if you have not done that yet.
  2. Now right click the project in Eclipse IDE and click “Properties” in the pop-up menu.
  3. Click “Targeted Runtimes
  4. Select the JEE runtime library that we created earlier
  5. Click OK button

Now we have configured Eclipse IDE environment to perform code analysis.

  1. Analyzing code using software analyzer

We are going to use the test application called EStore for our analysis purpose. This is a very simple web application and I just want to show the steps. The process remains the same for any type of JEE application.

  1. Right click on the Enterprise application project and click “Software Analyzer” from the popup menu
  2. Click on “Software Analyzer Configurations

  1. Click on the New icon to create a new configuration

  1. Let us give a name to this configuration, say “EStore migration”
  2. Click “Rules” tab
  3. Select WebSphere Application Server version Migration from RuleSets drop-down.

 

  1. Click Set button

  1. Select source and target application server versions

The selection of source and target application servers in this screen impacts the rules selected for the analysis. The Java version is 6 for both WAS 7.0 and WAS 8.0.

  1. Click OK button

Note that the software analyzer includes lots of other rules as well. These rules help in identifying and fixing issues that improve the quality of code. During migration avoid selecting rules that are not related to migration.

  1. Click Apply button
  2. Select the scope of the analysis using the “Scope” tab
  3. Click Analyze button

In the Software Analyzer Results view, the analyzer gives the summary of the run. The issues are shown under the tabs Java Code Review, XML File Review etc. In our case, the analysis did not highlight any issue.

 

To provide an idea of how the analyzer helps in fixing issues, I added few more rules that are related to code quality. As a result, a number of issues are highlighted as shown in the screen shot.

Note the following in the screenshot.

  1. On selecting an issue, the analyzer takes you to the source code that is related to the issue.
  2. The left margin of the editor contains icons which one can click to get further information on the issue.
  3. If a quick fix is available, then clicking the icon shows a popup with possible actions that one can take to fix the issue.

 

Once the changes are done, build the EAR file and install it using the scripts generated by WASPostUpgrade.sh.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Leave a Reply