MigrationToolkit en US 8.5.5.7

WebSphere Application Server
IBM WebSphere Application Server

Migration Toolkit
Version 8.5.5.7
IBM
Contents
Chapter 1. Overview . . . . . . . ..
Appendix A. Cloud migration rules
..
47
Chapter 2. What's new . . . . . . ..
Chapter 3. Support . . . . . . . . ..
Appendix B. WebSphere
version-to-version migration rules and
quick fixes . . . . . . . . . . . ..
49
Chapter 4. Installing the migration tools

Chapter 5. Uninstalling the migration
tools. . . . . . . . . . . . . . ..
13
Chapter 6. Installing IBM WebSphere

Application Server Developer Tools for
Eclipse. . . . . . . . . . . . . .. 15
Chapter 7. Importing applications into
the development environment. . . ..
17
Chapter 8. Shared Java projects . . ..
19
EAR-level library .
Web module library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
Chapter 9. Configuring a Java EE

Runtime Library . . . . . . . . . ..
19
19
21
Chapter 10. Migrating an application to

WebSphere Application Server . . .. 23
Configuring the application migration tool for
analysis. . . . . . . . . . . . . . ..
Analyzing code for migration . . . . . . ..
Application Evaluation Report . . . . . . ..
Running additional rules to optimize code quality
23
27
30
31
Chapter 11. Migrating Apache Tomcat

configuration to the Liberty profile. ..
33
Migrating Apache Tomcat server configuration

Migrating application configuration . . . .
Completing the generated configuration . . .
..
..
..
33
34
36
Chapter 12. Troubleshooting . . . ..
41
Troubleshooting the application migration tools ..

Software Analyzer options not shown . . ..
Java EE constructs or JSP not read correctly ..
Logging and trace . . . . . . . . . ..
Reports and history. . . . . . . . . ..
Markers . . . . . . . . . . . . ..
Known issues. . . . . . . . . . . ..
Troubleshooting the configuration migration tool ..
Known issues. . . . . . . . . . . ..
41
41
41
41
42
42
42
45
46
Copyright IBM Corp. 2009, 2015
Java code review .

JSP code review . .
XML code review .
File review . . .
Deprecated features
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
Appendix C. WAS Liberty migration

rules. . . . . . . . . . . . . . ..
Rules for the Application Evaluation Report
Rules for migrating applications to Liberty .
Java EE 7 behavior differences . . . . .
.
.
.
..
..
..
49
53
54
55
56
63
63
66
68
Appendix D. Java SE version migration 71

J2SE 5.0 compatibility impacts . .
Java SE 6 compatibility impacts. .
Oracle to IBM compatibility impacts
Sun internal APIs . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
71
73
73
75
76
77
Appendix E. Third-party application

server migration rules and quick fixes . 79
WebLogic Server rules and quick fixes . . . ..
WebLogic Server Java code review rules . . ..
WebLogic Server JSP code review rules . . ..
WebLogic Server XML file review rules . . ..
WebLogic Server file review rules . . . . ..
JBoss Application Server rules and quick fixes . ..
JBoss Java code review rules. . . . . . ..
JBoss Application Server JSP code review rules
JBoss Application Server XML file review rules
JBoss Application Server file review rules . ..
Oracle Application Server rules and quick fixes ..
Oracle Application Server Java code review rules
Oracle Application Server JSP code review rules
Oracle Application Server XML file review rules
Oracle Application Server file review rules . ..
Apache Tomcat rules and quick fixes . . . . ..
Apache Tomcat Java code review rules . . ..
Apache Tomcat JSP file code review rules . ..
Apache Tomcat XML code review rules . . ..
Common JSP code review rules. . . . . . ..
TLD file review rules . . . . . . . . . ..
Framework migration . . . . . . . . . ..
Framework XML - Spring best practices rules ..
Hibernate to WebSphere JPA migration . . . ..
Hibernate to WebSphere JPA - Java rules . ..
Hibernate to WebSphere JPA - XML rules . ..
79
79
83
83
86
87
87
88
88
89
90
90
91
91
93
93
93
93
94
94
95
95
96
97
97
99
iii
Appendix F. Migrated Apache Tomcat

configuration elements . . . . . ..
Configuration elements
conf/server.xml file .
conf/context.xml file .
conf/web.xml file . .
iv
that are
. . .
that are
. . .
that are
. . .
Application Migration Tools
migrated
. . .
migrated
. . .
migrated
. . .
from
. .
from
. .
from
. .
101
the
..
101
the
..
108
the
..
109
Configuration elements that are migrated

tomcat-users elements . . . . . .
application META-INF/context.xml file.
application WEB-INF/web.xml file . .
from
. .
from
. .
from
. .
..
the
..
the
..
Copyright and trademarks . . . . ..
110
110
111
113
Chapter 1. Overview
The IBM WebSphere Application Server Migration Toolkit provides a rich set of tools that help you
migrate applications from third-party application servers, between versions of WebSphere Application
Server, to the Liberty profile, and to cloud platforms such as Liberty for Java on IBM Bluemix.
For this release, all of the Eclipse-based source scanning tools are combined into one update site where
you can easily install the individual tools that you need. The new packaging includes the following tools:
v Cloud Migration Tool
v WebSphere Version to Version Application Migration Tool
v Apache Tomcat to Liberty Profile Configuration Migration Tool
v Apache Tomcat to WebSphere Application Migration Tool
v JBoss to WebSphere Application Migration Tool
v Oracle to WebSphere Application Migration Tool
v WebLogic to WebSphere Application Migration Tool
This document explains how to install, configure, and use the migration tools.
The application migration tools are based on IBM Rational Software Analyzer, which provides a single
solution to identify, analyze, and optimize the application health. The tools use the scanning capabilities
of Rational Software Analyzer to look for specific constructs unique to the particular application being
migrated. The tools then provide a way to review and change that data so that the application can run on
WebSphere Application Server.
Cloud migration tool

If you are moving an application to Liberty for Java on IBM Bluemix or a third-party cloud platform, the
Cloud Migration Tool offers additional advice, suggestions, and best practices to ensure that the
application runs correctly in those environments.
You can use this tool in combination with the version-to-version tool and the third-party tools to help
move your applications from WebSphere Classic, WAS Liberty, Apache Tomcat Server, JBoss Application
Server, Oracle Application Server, or Oracle WebLogic Server to IBM Bluemix and other cloud platforms.
WebSphere Version to Version Application Migration Tool

The WebSphere Version to Version Application Migration Tool assists in migrating applications from older
versions of WebSphere Application Server to WebSphere Application Server Version 7.0, 8.0, and 8.5.5. It
also helps you quickly and easily evaluate WebSphere Application Server full profile applications for their
readiness to run on the Liberty profile in both cloud and on-premises environments. For information
about how to generate this report, see Application Evaluation Report on page 30.
The overall application migration process between versions of WebSphere Application Server involves a
series of steps:
1. Assess the migration
2. Plan the work needed to migrate
3. Migrate and develop application code
4. Migrate the runtime configuration
5. Test applications with the new server configuration
6. Put the new server into production
The WebSphere Version to Version Application Migration Tool helps migrate and develop application
code.
The tool analyzes your application source code and highlights Java Platform, Enterprise Edition (Java EE)
programming model and WebSphere API differences between the profile types. Based on this analysis,
the tool offers advice and potential solutions to assess the ease of moving applications to the Liberty
profile. It also informs you of Java EE specification implementation differences that could affect your
applications.
There are a number of issues that can affect code migration and development when moving between
WebSphere Application Server releases. These issues include:
v Changes to the Java Runtime Environment (JRE) encountered in Java SE 5, 6, 7 and 8
v Removal of previously deprecated features
v Behavior changes in the product APIs
v Changes resulting from Java EE specification clarifications
v Deprecated features
v WebSphere APIs not available on Liberty
v Optional Java EE technologies not available on Liberty
v Differences in technology implementations
v Java EE 7 differences
The tool supports migrating from the following versions:
v WebSphere Application Server V5.1
v WebSphere Application Server V8.5.5 Classic
v WebSphere Application Server Liberty V8.5.5
The tool supports migrating to the following versions:
v WebSphere Application Server V8.5.5 Classic
v WebSphere Application Server Liberty V8.5.5
v WebSphere Application Server Liberty Core V8.5.5
Third-party application migration tools

The application migration tools flag known differences between applications hosted on Oracle WebLogic
Server, JBoss Application Server, Oracle Application Server, or Apache Tomcat and those hosted on
WebSphere Application Server. In many cases, the tools can automatically convert the different parts to be
compatible with WebSphere Application Server. If the tools cannot fix the difference, the file in question is
flagged to identify where design changes are needed. The tools support:
v Migrating applications to WebSphere Application Server Version 7.0, 8.0, or 8.5.5
v Migrating WebLogic Server Java, JSP, and class path artifacts (Java EE 5 and prior versions)
v Migrating WebLogic Server deployment descriptors (Java EE 5 and prior versions)
v Migrating JBoss Application Server Java and class path artifacts (Java EE 5 and prior versions)
v Migrating JBoss Application Server deployment descriptors (Java EE 5 and prior versions)
v
v
v
v
v
v
Migrating Oracle Application Server Java and JSP artifacts (Java EE 5 and prior versions)
Migrating Oracle Application Server deployment descriptors (Java EE 5 and prior versions)
Migrating Apache Tomcat Java and JSP artifacts (Java EE 5 and prior versions)
Migrating Apache Tomcat Context XML information contained in the application
Migrating from Apache Tomcat 6.0 or 7.0
Migrating from Java SE 1.4, 5, 6, or 7 to either Java 6, 7, or 8. Java 8 is supported only on the Liberty
profile.
Tomcat Configuration Migration Tool

The Configuration Migration Tool helps you move server and application configuration to the WebSphere
Application Server Liberty profile by automatically migrating portions of the configuration. The tool
supports:
v Migrating from Apache Tomcat 6.0 or 7.0
v Migrating to the WebSphere Application Server V8.5.5 Liberty profile
v Migrating Apache Tomcat context, server, and web XML information contained in the server
v Migrating Apache Tomcat context and web XML information contained in the application
WebSphere Configuration Migration Tool

The WebSphere Configuration Migration Tool (WCMT) is an Eclipse tool that reads the existing resources
from your server configuration from WebSphere V7.0 or later, WebLogic, or JBoss and creates equivalent
resources for WAS Liberty. It can optionally create a Jython script that you can use to create equivalent
resources in WebSphere Application Server V8.5.5 Classic.
You can download WCMT from the migration toolkit composite repository or separately from the
WASdev website, https://developer.ibm.com/wasdev/downloads/#asset/toolsWebSphere_Configuration_Migration_Tool.
The tool is available in English only.
Resources
With the Migration Toolkit for Application Binaries (Tech Preview), you can produce reports for your
application that highlight any Java EE programming model and WebSphere API differences between the
full and Liberty profiles from the command line using the application archives and class files.
Download the Migration Toolkit for Application Binaries from https://developer.ibm.com/wasdev/
downloads/#asset/tools-Migration_Toolkit_for_Application_Binaries_Tech_Preview
To estimate the effort required to move your applications from a third-party application server to
WebSphere Application Server, try the Migration Discovery Tool at http://www.ibm.biz/
MigrationDiscovery.
To learn more about migration, visit the WASdev migration landing page at https://developer.ibm.com/
wasdev/docs/migration/.
The IBM WebSphere Application Server Migration Toolkit developerWorks site provides information on
application and configuration migration from a third-party application server and version-to-version
application migration.
For comprehensive information on WebSphere Application Server migration topics, including examples of
using the migration toolkit, see the WebSphere Application Server V8.5 Migration Guide.
Chapter 1. Overview
Chapter 2. What's new

Packaging and installation
Version 8.5.5.7 of the application migration tools combines all of the tools in one update site. The online
update site also includes the WebSphere Configuration Migration Tool, which you can also download
separately from the WASdev website.
Cloud Migration Tool

The Cloud Migration Tool integrates the WAS Liberty to IBM Bluemix and Cloud Foundry rules from the
Liberty Tech Preview and provides a new Cloud Migration rule set that helps migrate any of the
WebSphere Classic or competitive application servers to cloud-based target environments.
Liberty profile Java EE 7 behavior differences

When moving an application from a Java EE 6 application server to a Java EE 7 application server, you
must consider changes that are required because of specification clarification and implementation
differences. The following Liberty profile Java EE 7 technologies are based on different implementations,
and these implementation differences result in application behavior changes.
v JAX-RS 2.0 is based on CXF, whereas JAX-RS 1.1 is based on Apache Wink.
v CDI 1.2 is based on the Weld implementation, whereas CDI 1.0 is based on Apache OpenWebBeans.
v JPA 2.1 is based on EclipseLink, whereas JPA 2.0 is based on OpenJPA.
This release includes migration assistance for the following Java EE 7 technologies:
v Contexts and Dependency Injection (CDI)
v Java API for RESTful Web Services (JAX-RS)
v Java Message Service (JMS)
v Java Persistence API (JPA)
Application Evaluation Report

The report now scans for the following technologies:
v Batch
v Interceptors
v JSON-P
Migration Toolkit for Application Binaries

The Migration Toolkit for Application Binaries was updated along with the Eclipse-based tool. You can
download an updated version of the binary scanning tool from the WASdev website.
Support
Bug and field support fixes were added to this release.
Chapter 3. Support
Supported platforms
The migration tools are supported on the following Eclipse-based platforms:
v Eclipse Kepler (4.3), Luna (4.4), and Mars (4.5)
v Rational Application Developer versions 8.5 to 9.1
v Rational Software Architect versions 8.5 to 9.1
Cloud Migration Tool

The cloud migration tool scans for known migration issues that you might encounter when you move
applications to a cloud platform. For more information, see Appendix A, Cloud migration rules, on
page 47.
WebSphere Application Server Version Migration Tool

The version-to-version migration tool scans for known issues in applications being migrated from
WebSphere Application Server Version 5.1, 6.0, 6.1, 7.0, or 8.0 to WebSphere Application Server Version
7.0, 8.0, or 8.5.5. It also scans for known issues in applications being migrated from WebSphere Classic to
WAS Liberty. See the following sections for rules that support WebSphere version-to-version migration:
v Appendix B, WebSphere version-to-version migration rules and quick fixes, on page 49
v Appendix C, WAS Liberty migration rules, on page 63
v Appendix D, Java SE version migration, on page 71
Third-party migration tools

The third-party application migration tools scan for known issues in applications that are migrated from
WebLogic Server, Oracle Application Server, JBoss Application Server, or Apache Tomcat to WebSphere
Application Server. Where possible, a quick fix is provided to change your code to a more portable
solution. See the following sections for supported rules and quick fixes for your third-party application
server:
v WebLogic Server rules and quick fixes on page 79
v JBoss Application Server rules and quick fixes on page 87
v Oracle Application Server rules and quick fixes on page 90
v Apache Tomcat rules and quick fixes on page 93
Updates with new rules and quick fixes are made available on developerWorks.
You can use the quick fix preview support in the migration tools to help you decide if you want to accept
the suggested code change. Also, view the help information provided with the rules to decide if you
want to run the quick fix. Always make a backup copy of your source code before you start a migration.
For some rules, the scan detects code that requires design changes and code rewrites. The tools highlight
these problem areas but do not provide a quick fix.
The Tomcat configuration migration tool migrates a subset of the server configuration and application
configuration from Apache Tomcat to the WebSphere Application Server V8.5.5 Liberty profile. For
information about which configuration elements are migrated, see Appendix F, Migrated Apache Tomcat
configuration elements, on page 101.
Resources
The migration tools do not identify all problems. As you encounter issues that the tools do not handle,
provide feedback through the IBM WebSphere Application Server Migration Toolkit forum, which is
available at http://www.ibm.com/developerworks/forums/forum.jspa?forumID=2106. You can also use
the forum to get answers to your questions about the tools.
If you have access to IBM Passport Advantage, you can also open a customer problem report.
As new rules and quick fixes are available, updates are made available on WASdev and Eclipse
Marketplace.

The migration tools are Eclipse features that you install into an existing Eclipse or Rational integrated
development environment (IDE). You can download Eclipse from http://www.eclipse.org. Eclipse IDE for
Java EE Developers is recommended for working with Java EE applications.
You can install all features of the migration toolkit directly from Eclipse Marketplace or from the online
repository. You can also manually download the repository archive. All options are described in the
following steps:
1. Start the IDE.
2. Uninstall any previous version of the migration toolkit.
3. Verify that the prerequisite plug-ins are installed in your IDE. In Rational Application Developer, all
prerequisite plug-ins are typically installed by default. In Rational Software Architect, the plug-ins are
not enabled by default. Use IBM Installation Manager to verify that the Business Intelligence and
Reporting Tools and the Web Developer Tools features are installed in your Rational product. If you
are using an Eclipse environment, verify that the prerequisite plug-ins for your particular Eclipse
version are installed.
a. From the Eclipse menu bar, select Help > Install New Software.
b. In the Work with field, enter the update site for your version of Eclipse:
v Eclipse 4.5: Mars - http://download.eclipse.org/releases/mars
v Eclipse 4.4: Luna - http://download.eclipse.org/releases/luna
v Eclipse 4.3: Kepler - http://download.eclipse.org/releases/kepler
c. Install the BIRT Framework listed in the Business Intelligence, Reporting and Charting feature.
Note: The catalog of available plug-ins is large and might require several minutes to download.
4. Install the migration tool features that you need.
a. Access the migration tool software. In Eclipse, you can install the tool directly from Eclipse
Marketplace. If you are using Rational Application Developer or do not have Eclipse Marketplace,
you can manually download and install the repository archive.
v To install the tool from the Eclipse Marketplace:
1) Go to Help > Eclipse Marketplace.
2) Search for WebSphere migration.
3) Under IBM WebSphere Application Server Migration Toolkit, click Install.
Figure 1. Accessing the migration tool software from Eclipse Marketplace
v To install from the online repository:

1) In your IDE, go to Help > Install New Software.

2) Click Add, and in the Add Repository window, enter the following information:
Name: WebSphere Migration Toolkit
Location:https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/
updates/wamt/MigrationToolkit/
3) Click OK.
v To install from the repository archive:
1) Download the latest version of the IBM WebSphere Application Server Migration Toolkit
from the WASdev website, https://www.ibmdw.net/wasdev/downloads/.
2) In your IDE, go to Help > Install New Software.
3) Click Add, and in the Add Repository window, enter the following information:
Name: WebSphere Migration Toolkit
Location: Click Archive and browse to the repository archive that you downloaded.
4) Click OK.
b. Expand IBM WebSphere Application Server Migration Toolkit, and select the migration tools
that you need for cloud, version-to-version, or third-party application server migration. Ensure
that Contact all update sites during install to find required software is selected, and click Next.
10
Figure 2. Selecting migration toolkit features
c. In the Install Details window, click Next.

d. In the Review Licenses window, read the terms and accept any license agreements. Click Finish.
The Installing Software window shows the installation progress.
e. When the Software Updates window is displayed, click Yes to restart the IDE.
11
12
Chapter 5. Uninstalling the migration tools

You can remove installed Eclipse features, such as the migration tools, by using the Eclipse Installation
Details window.
1. From the Eclipse menu bar, select Help > About Eclipse.
2. In the About Eclipse window, click Installation Details.
3. In the Eclipse Installation Details window, select the Installed Software tab.
4. Select the WebSphere Application Server migration toolkit feature that you want to uninstall, and click
Uninstall.
5. In the Uninstall window, click Finish.
13
14
Chapter 6. Installing IBM WebSphere Application Server

Developer Tools for Eclipse
If you develop applications in the Eclipse IDE, you can use the IBM WebSphere Application Server
Developer Tools in conjunction with the migration toolkit to migrate, develop, deploy, and test
applications within a single lightweight IDE. Using the tools, you can also manage the server, publish
your application to a local or remote server, and control incremental application publishing. Tools are
available for both the WebSphere Application Server Classic and WAS Liberty.
v IBM WebSphere Application Server Liberty Profile Developer Tools
v IBM WebSphere Application Server V8.5 Developer Tools
The tools can be installed easily within Eclipse from Eclipse Marketplace, or you can download and
install the tools from WASdev.net:
1. Start the Eclipse IDE.
2. To install the latest updates, go to Help > Check for Updates.
3. Access the development tool software.
To install from Eclipse Marketplace:
a. Click Help > Eclipse Marketplace.
b. Search for WebSphere developer.
c. In the list of results, locate the WebSphere Application Server Developer Tools for your version of
WebSphere Application Server, and click Install.
To download and install from WASdev.net:
a. Download the latest version of WebSphere Application Server Developer Tools from WASdev.net.
b. In your IDE, go to Help > Install New Software.
c. Click Add, and in the Add Repository window, enter the following information:
v Name: WebSphere Developer Tools
v Location: Click Archive and browse to the archive file that you downloaded.
d. Click OK.
4. In the Install Details window, click Next.
5. In the Review Licenses window, read the terms and accept any license agreements. Click Finish. The
Installing Software window shows the installation progress.
6. When the Software Updates window is displayed, click Yes to restart the IDE.
For general discussion, demos, and information links, go to http://wasdev.net for more information.
15
16
Chapter 7. Importing applications into the development

environment
To effectively analyze an application for migration, the application must be imported into your
Eclipse-based IDE, and the application modules must be organized in projects that reflect their structure
as EAR, web archive (WAR), and Enterprise JavaBeans (EJB) files. Specifically, migration rules that
analyze web and EJB bindings and extensions only work when analyzing projects created as dynamic
web projects and EJB projects.
To organize your files, you can either import your existing EAR, WAR, and EJB modules or manually
create new projects in the workspace for each EAR, WAR module, and EJB module. You can use the
Import Eclipse options to create the correct project structure. Rational Application Developer or the
Eclipse for Java EE developer tools are needed to create these projects properly.
For example, to import an EAR file, go to File > Import, select Java EE > EAR file. Enter the location of
your EAR file. Eclipse creates a project for the EAR file and a project for each module in the application.
Figure 3. Importing an EAR file
By importing the application, the proper project structure is created with the deployment descriptor
information. If your EAR file contains the Java source code, it is also imported into the Eclipse project.
However, most EAR and module files do not contain source code, and you need to copy the source code
to its correct source folders. Again, go to File > Import to import the source code from the file system or
from an archive (.zip) file. Repeat this procedure to import the source code for each module.
To create projects manually, go to File > New and select the appropriate project type:
v EAR file: Enterprise Application Project
v WAR file: Dynamic Web Project
v EJB module: EJB Project
To copy the source files to their correct locations in the project, go to File > Import.
Review the following guidelines for structuring projects:
17
v Place Java source code for a WAR file (for example, servlet, model, or utility classes) in the src folder
of the project. The src folder is defined and can be changed in the Java Build Path properties for the
project. If the Java source code needs to be referenced by more than one WAR file, see Shared Java
projects for information on structuring the project files.
v Place Java source code for an EJB module in the ejbModule folder of the EJB project.
v Place precompiled Java archive (JAR) libraries for a WAR file in the WebContent/WEB-INF/lib folder.
v Place EAR-level JAR libraries in the EarContent folder of the enterprise application project. If your
project contains an APP-INF/lib folder, place the folder in the EarContent folder; however, you must
run the class path rule and its quick fix to update the class paths correctly.
For a more detailed description of how to import applications into your IDE, see the WebSphere
Application Server V8.5 Migration Guide (http://www.redbooks.ibm.com/redbooks/pdfs/sg248048.pdf).
18
Chapter 8. Shared Java projects

There are two options for referencing shared Java classes from a web project:
1. Create a single copy of the Java project JAR file in the EAR file. Each WAR file references the JAR file.
This approach reduces the size of the EAR file.
2. Create a copy of the JAR file in each WAR file. Use this approach if only one WAR file references the
JAR file.
For more information on configuring the deployment assembly, see the Java EE Deployment Assembly
document on IBM developerWorks.
EAR-level library
Complete the following steps to place Java source files in a separate project:
1. Create a new Java project and add the Java source code into the src folder of the project.
2. Right-click the project in the Project view and select Properties.
3. Select the Deployment Assembly item from the left pane. On the right pane, click Add to include the
Java projects you want to reference.
Figure 4. Java EE EAR module dependencies
4. Click OK to save your changes.
Web module library

To create a copy of the JAR file in each WAR file, complete the following steps:
1. Right-click the project in the Project view and select Properties.
2. Select the Deployment Assembly item from the left pane to view the Web Deployment Assembly. On
the right pane, click Add to include the Java projects or archives you want to reference.
3. Click OK to save your changes.
19
20
Chapter 9. Configuring a Java EE Runtime Library

If you are using Eclipse with the Java EE tools installed, the Java compiler is not able to resolve
references to the Java EE APIs unless a target Java EE runtime environment is configured.
Follow these steps to configure the Java EE Runtime Library:
1. To open the Eclipse preferences, go to Window > Preferences.
2. Navigate to the Server > Runtime Environments item on the left pane.
Figure 5. Server Runtime Environments pane
3. Click Add. Select Basic > J2EE Runtime Library.

4. On the next wizard page, click Browse to choose the library location, locate the dev/JavaEE folder of
your WebSphere Application Server installation, and select the appropriate Java EE version. That
folder contains the j2ee.jar file with the Java EE APIs.
To use this runtime library in a web or EJB project when you have the IBM WebSphere Application
Server Developer Tools installed, target the full profile or Liberty profile server.
If WebSphere Application Server Developer Tools are not installed, you can set the library as a targeted
runtime in the project properties. In the Project view, right-click the project, and select Properties. Select
Targeted Runtimes, then select the recently configured Java EE runtime library, and click OK.
21
Figure 6. Targeted Runtimes
22
Chapter 10. Migrating an application to WebSphere

Application Server
Configuring the application migration tool for analysis
You can configure the tool to define a set of rules to run and define the scope of analysis within the
workspace. The scope can be a project, a working set, or the entire workspace. After you define the
scope, you can save the analysis configuration to use or modify later. With an application migration tool
installed, you have new analysis options to configure and run an analysis.
To configure the analysis, complete the following steps:
1. Open the analysis configuration options. You can access the configuration options in the following
locations within Eclipse:
v In the main Eclipse menu bar, go to Run > Analysis.
v In the Launch toolbar, click the Software Analyzer icon ( ) and select Software Analyzer
Configurations.
v In the Explorer view, right-click your project and select Software Analyzer > Software Analyzer
Configurations.
If you do not see Software Analyzer options, see Software Analyzer options not shown on page 41.
You can add or remove analysis configurations by using the icons in the window.
Figure 7. Creating a Software Analyzer configuration
2. In the configurations list, select Software Analyzer. Then, click New

changes to show the basic configuration interface.
. The right side of the window
23
Figure 8. Setting up the configuration
3. In the Software Analyzer Configurations window, enter a name for the configuration, such as
AppMigration.
4. On the Scope tab, select Analyze entire workspace to scan all projects in the workspace.
You can limit the scope of an analysis by using the other options to analyze a working set or a
selection of projects.
Tip: When you run your analysis from the Explorer view, the scope of the analysis is limited to the
node in the project where the menu item was selected. This allows you to perform a quick analysis on
a limited set of code.
5. On the Rules tab, select the type of analysis to perform using the Rule Sets list. You can also select
individual rules to run.
Tip: To obtain additional information about a rule, highlight the rule and press F1 (Shift-F1 for
Linux). Help for the rule is shown in the configuration window. The initial help page includes a short
description and a link to more information.
24
Figure 9. Selecting rules
Depending on which features you installed, you see one or more migration-related rule sets:
v Cloud Application Migration
v WebSphere Application Server Version Migration
v WebLogic Application Migration
v JBoss Application Migration
v Oracle Application Migration
v Apache Tomcat Application Migration
The application migration tools have rules under the following analysis providers:
v File Review
v Java Code Review
v JSP Code Review
v TLD File Review
v XML File Review
v XSL File Review
After you select a rule set, click Set to select the applicable application migration rules.
Chapter 10. Migrating an application to WebSphere Application Server
25
Figure 10. Configuring a rule set
Select the source and target settings for your environment:

Source application server
The source application server indicates the application server that you are migrating your
application from. The source application server, either WebSphere Application Server or a
third-party application server, affects the rules selected.
When using the WebSphere version-to-version rule set or the cloud migration rule set, you
can choose the source application server. For rule sets for third-party application servers, the
source application server is preselected and cannot be changed.
Target application server
The target application server indicates the application server that you are migrating to. You
can migrate to a specific version of WebSphere Application Server Classic, WAS Liberty, or
cloud platforms that run WAS Liberty.
If you are running WebSphere Application Server in a Docker container, select the target
application server based on the environment where your Docker container is running. For
example, if you run WebSphere in an on-premises Docker container, select WebSphere
Application Server V8.5.5 Classic, WAS Liberty Core V8.5.5 or WAS Liberty V8.5.5 as your
target application server. If you are using Docker in the Bluemix IBM Container Service, select
Liberty for Java on IBM Bluemix as your target.
Target Java EE version
When migrating to WAS Liberty, you can also select the target Java Platform, Enterprise
Edition (Java EE) version that you plan to use for the application.
If you need new Java EE 7 features and want to move to the latest Java EE level, you might
experience different behaviors. The Java EE rules help you understand these differences and
how they will affect your application. The rules can help you move from Java EE 6 on either
WAS Liberty or WebSphere Classic to Java EE 7 on WAS Liberty. If you are already on WAS
Liberty Java EE 6, you can stay on your current Java EE level with zero migration.
Choose only the technologies that you must migrate. Some technologies, such as JPA, do not
need to be migrated. Consider keeping existing JPA applications running on the Java EE 6 JPA
2.0 feature based on OpenJPA, and look at the new version of JPA based on EclipseLink for
new applications.
Source Java version
The source Java version indicates the Java Platform, Standard Edition (Java SE) version that
your application server currently uses.
26
Target Java version

The target Java version indicates the Java SE version that your target application server will
use. If the source and target Java versions are different, migration rules are automatically
selected.
Note: The number of rules in the analysis configuration options varies depending on the platform on
which the tool is installed. Analysis rules are available in several Rational products such as Rational
Application Developer; therefore, the included rule sets might be different.
6. To save the rule configuration, click Apply.
7. In the Software Analysis Configurations window, you can select or clear any rule or group of rules to
use in the analysis. For example, if you find after analysis that you do not need to make changes
pointed out by a particular rule from the selected rule set, you can clear its selection to turn it off.
a. To find the rule, the navigation in the configuration window is similar to the folders shown in the
results tree view. Use the folder names to locate the rule.
b. Clear the rule selection.
c. Click Apply.
The deselected rule will not be included in the next analysis.
Some rules have additional configuration options. When a rule with configuration options is selected, the
rule properties are shown in the Properties tab under the list of rules. The following figure shows the rule
properties for a web services rule. If you do not update the properties, the rule uses the default values.
Figure 11. Rule properties
Analyzing code for migration

Run the analysis and display the results.
27
To start the analysis, click Analyze in the Software Analyzer Configuration window. The results are
displayed in the Software Analysis Results view.
Figure 12. Java Code Review results view
The content of the results view varies depending on which rules you are running. The results generated
by an application migration tool are displayed in one of the following tabs:
v File Review
v Java Code Review
v JSP Code Review
v TLD File Review
v XML File Review
v XSL File Review
If no results are shown in the panel, no issues were identified while scanning.
Right-click individual results to show the available options such as viewing the source code where the
problem occurred or correcting the problem with a provided fix.
28
Figure 13. Result options with Quick Fix Preview and Help
Not all rules have all actions available, but the possible actions include:
v View Result - Opens an editor showing the source file that triggered the rule. The cause of the
problem is highlighted, and a rule violation icon is shown in the left margin of the editor.
Quick Fix - The light bulb overlay on the result list icon (
) indicates that this rule has a quick fix.
Selecting this option runs the conversion that modifies the affected Java code, XML file, JSP or manifest
file, allowing it to run in WebSphere Application Server. The quick fix might change the code directly
or it might present the steps needed to complete the fix.
v Quick Fix Preview - This option is available for the rules that support showing a side-by-side
comparison of the original code and the code after the quick fix is applied. This option allows you to
see the changes before they are made.
Some quick fixes modify more than one file. When you select Quick Fix Preview for a fix affecting
multiple files, the files are shown in the Structure Compare portion of the Compare view. Double-click
each file to view the differences.
v
29
Figure 14. Previewing quick fixes for multiple files
Ignore Result - This option removes the rule from the list without making a code change. For Java
and XML files, a comment annotation is added to the file so that the rule is not triggered on future
analysis runs.
v Quick Fix All - This option resolves all issues identified for a given rule.
v Quick Fix All Category - This option runs all quick fixes identified for the category to which the rule
belongs. A rule must have Quick Fix All enabled for the Quick Fix All Category option to run its
quick fix. For example, if you choose this option on a Java rule, the quick fixes for all Java rules that
have the Quick Fix All option are run.
v
Context-sensitive help is displayed in the Help view as you select each result. The first panel is a short
description. Click Detailed Help to get more information. Press F1 to open the Help view if it is not
already displayed.
Application Evaluation Report

The WebSphere Version to Version tool can generate a report that helps to evaluate the Java technologies
that are used by your application. The report gives a high-level review of the programming models found
in the application and the WebSphere products that support these programming models.
To
1.
2.
3.
4.
30
generate the report:

Click Run > Generate Application Evaluation Report.
Select the projects that you want to evaluate.
Select the WebSphere products you want to compare.
Click OK.
Figure 15. Application Evaluation Report
The rows in the report vary depending on the application.
Running additional rules to optimize code quality

After you successfully migrate your application, Rational Software Analyzer provides additional rules
that can help improve the quality of your code. Figure 16 shows examples of the additional rules.
Figure 16. Other architectural and Java rules
Access these rules by creating a new analysis configuration or modifying an existing one. These rules are
not automatically selected as part of rule sets for the application migration tools.
When the selected rules are run and necessary changes are made, the updated application must be
exported and tested on WebSphere Application Server. If you use Rational Application Developer, tools
are available to create deployments and test the application within the Rational Application Developer
environment.
31
Some uses have found the Avoid using com.ibm.ws.* package rule in the Java Code Review > Private API >
WebSphere category helpful during migration analysis. The com.ibm.ws.* package contains
application-server-internal APIs that are not for application use and are subject to change. If you know
your application uses private APIs or if you are not sure, you can use this rule to check your application.
If you have generated code related to EJBs or web services, you might get false hits on this rule.
32
Chapter 11. Migrating Apache Tomcat configuration to the

Liberty profile
Migrating Apache Tomcat server configuration
Begin your configuration migration process by migrating the Apache Tomcat server configuration. Before
you run the configuration migration tool, the Liberty profile server must already exist in Eclipse. To
create a Liberty profile server in Eclipse, you must use the WebSphere Application Server V8.5 Liberty
Profile Tools. For more information, see Chapter 6, Installing IBM WebSphere Application Server
Developer Tools for Eclipse, on page 15
To migrate the server configuration, complete the following steps:
1. Start the migration tool. You can start the migration tool from the following locations within Eclipse:
v In the Eclipse menu bar, go to Run > Tomcat Configuration Migration. Browse to the location of
the Tomcat server installation, and click OK.
v In the Explorer view, right-click your Tomcat server and select Migrate Tomcat Configuration.
v In the Servers view, right-click your Tomcat server and select Migrate Tomcat Configuration.
2. Select the Liberty profile server that you want to migrate to. Click OK to begin migrating the
configuration.
3. After the configuration is migrated, you are notified that the migration completed successfully and
whether further action is required. Select whether you want to open the updated Liberty profile
server configuration and the server migration log file, and click OK. The Liberty profile server
workspace refreshes.
The selected Liberty profile server now contains the updated configuration. The server.xml file contains
an include of the migratedConfig/server-updates-for-config.xml file.
The updated configuration includes the following files:
File name
Description
server.xml
Liberty profile server configuration file that

was updated to include the generated
configuration file, migratedConfig/serverupdates-for-config.xml
migratedConfig/configMigration.log
Information on the migration
33
File name
Description
migratedConfig/context.xml
Configuration from the Tomcat context.xml

file
migratedConfig/server.xml
Configuration from the Tomcat server.xml

file
migratedConfig/server.xml.original.txt
Copy of the original Liberty profile

server.xml file before the migration
migratedConfig/server-updates-for-config.xml
High-level include file
migratedConfig/shared-libraries.xml
Shared library configuration for reference by

Liberty profile datasource elements and the
classloader element on the application
element
migratedConfig/shared-libraries.xml.original.txt
Copy of the original shared-libraries.xml

file before the migration. This copy is made
only if the file existed and was modified
during the migration.
migratedConfig/variables.xml
Configuration from the Tomcat

catalina.properties file
migratedConfig/variables.xml.original.txt
Copy of the original variables.xml file before

the migration. This copy is made only if the
file existed and was modified during the
migration.
migratedConfig/[tomcat-users-file]_users-and-roles.xml

tomcat-users.xml file or a user-defined file
with tomcat-users elements. The Liberty
profile file name is created based on the
Tomcat file name.
Migrating application configuration

After you migrate the Apache Tomcat server configuration, you can migrate the application configuration.
Before you run the configuration migration tool, the application WAR file must be imported into Eclipse,
and the application source, which can include Java source code, JavaServer Pages (JSP), and deployment
descriptors, must be migrated using the Apache Tomcat to WebSphere Application Migration Tool. For
information about configuring and running the application migration tool, see Configuring the
application migration tool for analysis on page 23 and Analyzing code for migration on page 27.
To migrate the application configuration, complete the following steps:
1. In the Explorer view, right-click the project, and select Migrate Tomcat Configuration.
2. Select the Liberty profile server that you want to migrate to, and click OK to begin migrating the
configuration.
3. If you are migrating an application before you migrated the corresponding Tomcat server, you can
choose to migrate a server before you continue to migrate the application. Select whether you want to
migrate a Tomcat server, and click OK. To stop migrating the application, click Cancel.
34
4. After the configuration is migrated, you are notified that the migration completed successfully and
whether further action is required. Select whether you want to open the updated Liberty profile
server configuration and the application migration log file, and click OK. The Liberty profile server
workspace refreshes.
The selected Liberty profile server now contains the updated configuration. The server.xml file contains
an include of the server-updates-for-application.xml file.
The updated configuration includes the following files:
File name
Description
server.xml
Liberty profile server configuration file that

was updated to include the generated
configuration file, migratedConfig/
[application-name]/server-updates-forapplication.xml
migratedConfig/[application-name]/configMigration.log
Information on the migration
migratedConfig/[application-name]/application-configcontext.xml
Configuration from the application

META-INF/context.xml file
migratedConfig/[application-name]/application-config-web.xml
Configuration from the application

WEB-INF/web.xml file
migratedConfig/[application-name]/ibm-web-bnd.xml.original.txt Copy of the original application

WEB-INF/ibm-web-bnd.xml file before the
migration. This copy is made only if the file
existed and was modified during the
migration.
Chapter 11. Migrating Apache Tomcat configuration to the Liberty profile
35
File name
Description
migratedConfig/[application-name]/server.xml.original.txt
Copy of the original Liberty profile

server.xml file before the migration
migratedConfig/[application-name]/server-updates-forapplication-config.xml
High-level include file
migratedConfig/shared-libraries.xml
Shared library configuration for reference by

Liberty profile datasource elements and the
classloader element on the application
element
migratedConfig/shared-libraries.xml.original.txt
Copy of the original shared-libraries.xml

file before the migration. This copy is made
only if the file existed and was modified
during the migration.
migratedConfig/variables.xml

catalina.properties file
migratedConfig/variables.xml.original.txt
Copy of the original variables.xml file before

the migration. This copy is made only if the
file existed and was modified during the
migration.
Completing the generated configuration

After the tool migrates the Apache Tomcat server and application configuration to the Liberty profile, you
might need to take further action to complete the generated configuration. Whether further action is
required is noted in the dialog box that opens when the configuration is migrated successfully and in the
migration log file, configMigration.log. The migration log includes the following entries that detail what
you must do to complete your configuration:
v ** Action required: These log entries denote elements that must be configured further.
v ** Attention: These log entries denote elements that were not migrated or that behave differently in
the Liberty profile compared to Tomcat. You must evaluate whether further actions are necessary to
complete the configuration.
The configMigration.log file is located in the migratedConfig directory for a migrated server and in the
migratedConfig/[application-name] directory for a migrated application.
The following sections contain information on elements that require additional action:
Migrating JMS Resource elements for Apache ActiveMQ

To support the migration of JMS applications, Tomcat Resource elements related to Apache ActiveMQ are
migrated to the embedded Liberty profile messaging features and related configuration elements in the
Liberty profile server. The applications must use JMS interfaces to function properly when configured to
use the Liberty profile embedded messaging engine.
Migrating JMS Resource elements for WebSphere MQ

Tomcat Resource elements related to WebSphere MQ are migrated to Liberty profile WebSphere MQ
configuration elements. To connect to WebSphere MQ from the Liberty profile, you must use the
WebSphere MQ resource adapter, which must be installed separately. For more information about
installing the WebSphere MQ resource adapter for the Liberty profile, see http://www.ibm.com/support/
docview.wss?uid=swg21633761.
36
The location of the WebSphere MQ resource adapter is specified in the generated configuration by the
wmqJmsClient.rar.location variable. The default location is ${shared.resource.dir}/wmq/wmq.jmsra.rar.
Copy the files to the specified location, or modify the wmqJmsClient.rar.location variable to reference
the location of the WebSphere MQ resource adapter files.
To allow JMS applications to connect to WebSphere MQ in BINDING mode or by using the shared
memories, you must have both the Liberty profile and WebSphere MQ deployed on the same server. To
allow JMS applications to connect in BINDING mode, you must also manually specify the location of the
WebSphere MQ native libraries in the generated configuration on the nativeLibraryPath attribute of the
wmqJmsClient element.
Migrating applications that use MongoDB

Although Tomcat applications that use MongoDB do not need to reference the MongoDB Java driver,
Liberty profile applications that use the MongoDB Java driver as a shared library require a library
reference to the driver. To support the migration of applications that use MongoDB and reference it as a
shared library, the migration tool generates shared library configuration and specifies the location of the
MongoDB Java driver on the library element. The default location of the driver is
${shared.resource.dir}/mongo-java-driver-*.jar.
The migration tool attempts to copy the required driver file from the Tomcat server runtime directory
that was used in the most recent Tomcat server configuration migration to the location specified on the
library element. The Tomcat server runtime directory is saved in the migratedConfig/server-updatesfor-config.xml file in the tomcatServerRuntimeDirectory variable. If tomcatServerRuntimeDirectory is
not specified, the migration tool attempts to copy the required file from the location specified by the
CATALINA_HOME system environment variable.
If the required driver file is not found, an ** Action required: entry is logged. You must copy the file to
the specified location or modify the library element to reference the location of the driver.
Migrating database Resource elements

To support the migration of applications that use databases, Tomcat Resource elements that are related to
IBM DB2, Apache Derby, Oracle Database, Sybase ASE, Microsoft SQL Server, and MySQL are migrated
to dataSource configuration elements in the Liberty profile server. The generated configuration looks for
certain files in the location specified by the ${shared.resource.dir} property. Applications that use
MongoDB also generate a library configuration element.
The migration tool attempts to copy the required files from the Tomcat server runtime directory that was
used in the most recent Tomcat server configuration migration to the location specified by the
${shared.resource.dir} property. The Tomcat server runtime directory is saved in the
migratedConfig/server-updates-for-config.xml file in the tomcatServerRuntimeDirectory variable. If
tomcatServerRuntimeDirectory is not specified, the migration tool attempts to copy the required files
from the location specified by the CATALINA_HOME system environment variable.
If the required driver files are not found, an ** Action required: entry is logged. You must copy the files
to the specified location or modify the generated configuration to reference the location of the files.
The files for each database type are listed in the following table.
Database
Expected files in the location specified by the

${shared.resource.dir} property
Apache Derby
derby.jar
IBM DB2
db2jcc4.jar and either db2jcc_license_cisuz.jar or

db2jcc_license_cu.jar
37
Database
Expected files in the location specified by the

${shared.resource.dir} property
Oracle Database, Thin driver
ojdbc6.jar
Oracle Database, OCI driver
All contents of the Oracle Database client directory
Sybase ASE, JDBC3 driver
jconn3.jar
Sybase ASE, JDBC4 driver
jconn4.jar
Microsoft SQL Server, Microsoft JDBC driver
sqljdbc4.jar
Microsoft SQL Server, Progress DataDirect driver
sqlserver.jar
MySQL Server
mysql-connector-java-version.jar, where version is the

version of the MySQL JDBC driver
MongoDB, Java driver
mongo-java-driver-version.jar, where version is the

version of MongoDB Java driver
Note: If the Oracle OCI driver is present in the Tomcat source configuration, the generated library
configuration is not contained within the JDBC driver configuration as it is for the other databases. The
library for the OCI driver must be shared across all applications. Therefore, the library is generated in a
separate include file, migratedConfig/shared-libraries.xml. The ID of the library is then referenced on
the libraryRef attribute of the jdbcDriver element. Because the migration tool cannot determine the
location of the Oracle Database client directory, the required files are not copied during the migration
process.
Migrating tomcat-users elements

The following configuration files that contain tomcat-users elements are migrated:
v Files that are referenced by the pathname attribute of a MemoryRealm element
v Files that are referenced by the pathname attribute of a Resource element that uses the
MemoryUserDatabaseFactory factory attribute and is referenced by a UserDatabaseRealm Realm element
v The conf/tomcat-users.xml file if a previously described MemoryRealm element or Resource element
does not define a pathname attribute
A file that is referenced in the pathname attribute can be relative to the Tomcat server directory or an
absolute file name. Because more than one realm can be configured, multiple configuration files that
contain tomcat-users elements could be migrated. To avoid file name conflicts in the migrated files, the
generated Liberty profile file name is derived from the Tomcat configuration file name and directory. For
example, conf/tomcat-users.xml is migrated to migratedConfig/conf_tomcat-users_users-androles.xml.
Migrating application security-role elements

In Tomcat, the meaning of security-constraint/auth-constraint/role-name elements that are set to * is
defined by the value of the allRolesMode attribute on either the UserDatabaseRealm configuration or the
MemoryRealm configuration. The allRolesMode attribute can have the following values:
v allRolesMode="strict" - All defined security-role elements from the application web.xml file are
migrated to the Liberty profile application-bnd security-role and group elements.
v allRolesMode="authOnly" - A Liberty profile application-bnd element is created with a security-role
element that defines a special-subject element with the type attribute set to
ALL_AUTHENTICATED_USERS.
v allRolesMode="strictAuthOnly" - If the security-role elements are defined in the application web.xml
file, the values are migrated as they are in strict mode. If no roles are defined, the migration proceeds
as for the authOnly mode.
38
If the allRolesMode attribute is not defined, the default value is strict. If multiple realms define different
allRolesMode values, the most flexible value is migrated, according to the following order: authOnly, then
strictAuthOnly, then strict.
Migrating SSL-enabled connectors

All supported SSL connectors are migrated to equivalent httpEndpoint elements. Supported protocol
types are "HTTP1.1", "org.apache.coyote.http11.Http11Protocol",
"org.apache.coyote.http11.Http11NioProtocol", or no specified protocol, which is the default value.
Connectors that use other protocol types are not migrated.
Connectors that redirect to SSL-enabled connectors are associated together on the httpPort and httpsPort
attributes of the httpEndpoint elements. Keystore and truststore passwords are encoded during
migration. If a port redirects to an SSL-enabled connector that does not exist or is an unsupported
protocol, the httpsPort attribute is set to -1, which disables the port.
Multiple ports cannot redirect to the same SSL-enabled port on the Liberty profile. If this configuration is
detected, the migration tool associates only the first httpEndpoint with the SSL-enabled port and sets the
httpsPort attribute to -1 on the remaining httpEndpoint elements that are generated.
If the Tomcat connector requires security but does not provide keystore information, the migration tool
generates the default SSL configuration supported by Liberty.
Migrating variables
The migration tool migrates variables that are referenced in the Tomcat configuration to the Liberty
profile server configuration. Variable definitions in the Tomcat catalina.properties file are migrated to
the migratedConfig/variables.xml file by default. If a variable is not defined in the catalina.properties
file or as a system property, an ** Action required: entry is logged. Configure the variable in the Liberty
profile server, or modify the configuration to not reference the variable.
The Liberty profile does not support variable names that contain the string "${". If a variable name
contains this string, an ** Action required: entry is logged. Configure a variable with a valid name, or
modify the configuration to not reference the variable.
If a variable has a value that contains the name of another variable, the Liberty profile server interprets
the value differently than Tomcat. The Liberty profile server interprets the value as referencing another
variable, whereas the Tomcat server interprets the value as a literal string. If a variable has a value that
the Liberty profile might interpret as a variable reference, an ** Action required: entry is logged.
Configure a variable without a variable reference in its value, or modify the configuration to not reference
the variable.
Configuring a virtual-host element for an application

To bind an application on a Liberty profile server to a particular virtual host, the application
ibm-web-bnd.xml file must contain a virtual-host element. The value of the virtual-host name attribute
must be the value of a virtualHost id attribute that is configured in the Liberty profile server in the
migratedConfig/server.xml file. You can select a virtual host for your application when you migrate the
application.
39
40
Chapter 12. Troubleshooting

Troubleshooting the application migration tools
Software Analyzer options not shown
Installing an application migration tool creates a Software Analyzer menu and toolbar options in the Java,
Debug, Plug-in Development, and C++ perspectives. When you use other perspectives, you must enable
these options manually by completing the following steps:
1. From your perspective, select Window > Customize Perspective from the IDE menu.
2. In the Customize Perspective window, click the Commands tab and select Software Analyzer.
3. Click OK.
Figure 17. Software Analyzer availability
Java EE constructs or JSP not read correctly

For the tools to read project files correctly, the projects must be set up with their appropriate project
facets. For example, projects that contain enterprise beans must have the EJB Module facet. You can see
facets for a project by right-clicking the project in the project explorer and selecting Properties. Select the
Project Facets property. Projects containing web modules must be dynamic web projects. See Chapter 7,
Importing applications into the development environment, on page 17 for more information.
Logging and trace

The application migration tools write error information to two log files:
v The workspace log (workspace/.metadata/.log) contains messages logged by the application migration
tools and messages logged by Rational Software Analyzer.
v The service logs for the application migration tools are located in the workspace/.metadata/.plugins/
com.ibm.ws.appconversion.base directory. These logs contain all error information. If trace is enabled,
the logs also contain detailed trace information.
Enable trace in the migration tools by setting the appconversion.trace system variable on the command
line to launch the IDE or in the eclipse.ini properties file; for example:
41
Command-line option. Add the system variable to the command line that starts Eclipse: eclipse.exe
-vmargs -Dappconversion.trace=true
v eclipse.ini option. Add the following option to the eclipse.ini file found in the same directory as the
eclipse.exe file: -Dappconversion.trace=true
v
Reports and history

In the Software Analyzer Results window, you can export a history of each analysis provider for the
selected analysis run. Export the history as XML data or generate a formatted HTML or PDF file by
clicking on the respective icons in the upper-right corner of the analysis provider tab.
Generated PDF reports are saved in the workspace/.metadata/.plugins/
com.ibm.xtools.analysis.reporting/reports directory.
Markers
Markers are displayed in the left margin of Eclipse editors and provide information about the content of
the editor on the line where the marker is displayed. Editors for different file types can have different
behaviors for the markers, some of which are described here.
Figure 18. Analysis rule markers in a Java editor
No pop-up window displays when you click the marker

This issue affects non-Java based rules. For a Java rule, clicking the marker allows the quick fix to be
performed. However, clicking the marker for the XML rule has no action, and hovering over the marker
only displays the help text. Use the Software Analyzer Results view to select the Quick Fix action in
non-Java files.
Double-clicking a marker removes the marker

Double-clicking the marker in the file editor removes the marker without applying the quick fix. If this
happens, run the analysis again to flag the problem again.
Cannot select multiple markers on the same line

When there are multiple markers on the same line of text, you cannot toggle between the different
markers. You must carry out the action of the first marker to select successive markers. To apply a quick
fix in such a case, use the Software Analyzer Results view to select the Quick Fix action you want, rather
than relying on the marker.
Known issues
Quick Fix for a WebLogic rule corrupts the ejb-jar.xml file
If you are using Eclipse 4.3 or later without the WebSphere Application Server Developer Tools installed,
namespace attributes in the ejb-jar.xml file are corrupted when you use the Quick Fix option for the
WebLogic rule Do not use local JNDI names. This rule is found on the XML File Review tab under
WebLogic To WebSphere deployment descriptor migration in the Software Analyzer Results view.
When this issue occurs, you will see the following message in the Markers tab under XML Problems:
Attribute "xmlns" was already specified for element "ejb-jar".
If you run analysis again, you will see the following message in the error log:
42
The ejb-jar.xml file in the weblogicApp project cannot be analyzed because of the following
XML parsing exception: org.xml.sax.SAXParseException: Attribute "xmlns" bound to namespace
"http://www.w3.org/2000/xmlns/" was already specified for element "ejb-jar".
The Quick Fix erroneously duplicates the xmlns attribute and changes the value of the xmlns:ejb attribute
as shown in the following example.
Namespace attributes before you run the Quick Fix:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:ejb="http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
id="ejb-jar_ID" version="3.0"
Namespace attributes after you run the Quick Fix:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:ejb="http://java.sun.com/xml/ns/javaee" xmlns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
id="ejb-jar_ID" version="3.0"
To resolve the parsing errors, manually edit the ejb-jar.xml file and fix the namespace attributes. For
information about installing the developer tools so that this issue does not occur, see Chapter 6,
Installing IBM WebSphere Application Server Developer Tools for Eclipse, on page 15.
Quick Fix All Category

When you use the Quick Fix All Category option, let it run to completion before running it on another
rule provider. Also, do not run Quick Fix All Category again on the same provider where it is already
running. Wait until it completes.
If you notice errors being logged when running the Quick Fix All Category option, there are a few
things you can do in Eclipse to mitigate issues:
v In Window > Preferences > General > Editors, select Close editors automatically and set a value for
Number of open editors before closing. The default value is 8, but you can limit it further.
v Choose Run in Background to prevent all the editors from opening and possibly running out of
window handles.
v Disable the automatic build feature of Eclipse (Project > Build Automatically) while running Quick
Fix All Category. Manually build the projects, and enable the option again after running Quick Fix All
Category.
Process all rules of a category before running analysis again.

Some rules are interrelated, and you might improve results if you run related quick fixes before running
the analysis again. For example, the triggers for the WebLogic Server logging rules are related, and you
will need to apply all quick fixes related to logging to make sure that the changes can compile
successfully.
Multiple rules on the same node

When multiple rules are flagged on the same node, only the first quick fix applied runs correctly. You
might need to run the analysis multiple times to make sure that all code is fixed and processed correctly.
Viewing external links from help in Linux

Many detailed help pages have external references to information applicable to the specific rule. This
information is best viewed from an external browser rather than the Eclipse help view. On Windows
platforms, help automatically launches these external references in the default browser. On Linux
43
operating systems, it displays the information in the Eclipse help view. To manually open help in an
external browser, use the Show in external window icon ( ) on the detailed help page.
Ignore Results
If you select Ignore Results on a line of code that is the beginning of a block of Java code with nested
results that are flagged for the same rule, the nested results line numbers are set to zero. You can rerun
the analysis to see the proper line numbers. Examples of statements that cause this issue are method
declarations and if statements.
View Results for .xmi files

If you select View Results for an .xmi file and get an error when you open the file, add an .xmi file
association. Go to Window > Preferences > General > Editors > File Associations, click Add, and enter
*.xmi. Select either XML Editor or Text Editor, and click Default. Click OK to save.
Rational Application Developer installation dependency conflicts

If an application migration tool installation fails with a conflicting dependency error, you might need to
remove the Rational Application Developer Code Analysis or Code Review feature. The feature name
depends on your Rational product version.
The following message is an example of a code dependency error:
Cannot complete the install because of a conflicting dependency.
Software being installed: Application Migration Tool - WebSphere Version to Version 3.0.1.201111170830
com.ibm.ws.appconversion_feature.was2was.feature.group 3.0.1.201111170830)
Software currently installed: Shared profile 1.0.0.1322626949228 (SharedProfile_bootProfile 1.0.0.1322626949228)
Only one of the following plugins can be installed at once:
Analysis History Data Source ODA Runtime Driver 7.0.100.v20100517_2203 (com.ibm.rsar.analysis.reporting.oda 7.0.100.v20100517_2203)
Analysis History Data Source ODA Runtime Driver 7.0.100.201111170830 (com.ibm.rsar.analysis.reporting.oda 7.0.100.201111170830)
To uninstall the Rational Application Developer Code Analysis or Code Review feature, start IBM
Installation Manager, and select the Modify option. Select your Rational Application Developer
installation from the Modify Packages list. Click Next, and clear Code Analysis selection from the list of
features. Click Next, and verify that Code Analysis is in the list of features to be removed. Proceed with
the removal of the feature.
After Installation Manager completes, install the toolkit again.
Java Code Review Severity Summary HTML report in Windows does not display
The Java Code Review Severity Summary HTML report in Windows does not display in the Eclipse
HTML viewer unless you use Internet Explorer 9, which supports SVG image files.
You can work around this problem in the following ways:
v Produce a PDF file instead of an HTML file.
v Produce an HTML file, right-click the view to Create Shortcut, then open the shortcut using a browser
that supports SVG files on Windows, such as Mozilla Firefox.
Rule selection does not display correctly in Linux

If you are using Eclipse 4.4 or later on Linux, selecting a rule set in the Software Analyzer Configurations
selects the appropriate rules, but the selection indicator before the category names does not display
correctly under the Analysis Domains and Rules panel. However, the number of rules selected is
indicated correctly after each category name.
44
In versions of Eclipse prior to 4.4, a check mark indicates that all rules in a category are selected, and a
minus sign indicates that some of the rules in a category are selected. In Eclipse 4.4 or later, the indicator
on the category might be blank, even though some or all the rules within that category are selected. The
analysis is not affected.
Troubleshooting the configuration migration tool

No servers are listed in the Liberty Profile Server Selection window
The list of servers in the Liberty Profile Server Selection window is populated with Liberty profile servers
found in the Servers view of Eclipse. If no Liberty profile servers are present, no servers are listed. Cancel
the migration, add a Liberty profile server to Eclipse, and start the migration again.
No servers are listed in the Tomcat Server Selection window

The list of servers in the Tomcat Server Selection window is populated with Tomcat servers found in the
Servers view of Eclipse. If no Tomcat servers are present, no servers are listed. In the Tomcat Server
Selection window, click Cancel to return to the Dependencies on the Tomcat Configuration window. In
the drop-down list you can choose to migrate a Tomcat server from the file system or migrate only the
application. Alternatively, click Cancel to cancel the application migration, then add a Tomcat server to
Eclipse and start the application migration again.
The application receives a SQLException

The generated data source configuration looks for the necessary database JAR files in the location
specified by ${shared.resource.dir}. Copy the relevant JAR files to the specified location, or change the
dataSource configuration element in the Liberty profile server to reference the location of the JAR files.
A JMS Application receives a NamingException caused by a

ClassNotFoundException
The location of the WebSphere MQ resource adapter is specified in the generated configuration by the
wmqJmsClient.rar.location variable. The default location is ${shared.resource.dir}/wmq/wmq.jmsra.rar.
Copy the files to the specified location, or modify the wmqJmsClient.rar.location variable to reference
the location of the WebSphere MQ resource adapter files.
A JMS Application receives a DetailedJMSException caused by an

UnsatisfiedLinkError
The generated configuration for a JMS application that connects to WebSphere MQ in BINDING mode
must be updated manually to reference the location of the WebSphere MQ native libraries. Specify the
location of the libraries on the nativeLibraryPath attribute of the wmqJmsClient element.
The application receives a message that the authentication did not succeed
The user elements in the Tomcat server configuration contained encrypted passwords, so the passwords
could not be hash encoded during migration. Use the Liberty Profile Configuration Editor to change and
hash encode the password attributes in the migrated configuration to the original unencrypted values
from the Tomcat server.
There are multiple available UserRegistry implementation services

After you migrate the Tomcat configuration, if you see the CWWKS3006E error message when you start
the Liberty profile server, there might be one or more basicRegistry elements with differing id attribute
values.
45
CWWKS3006E: A configuration exception has occurred.

There are multiple available UserRegistry implementation services;
the system cannot determine which to use.
All migrated basicRegistry elements are created with the id attribute value set to migratedUserRegistry.
If there are one or more existing basicRegistry elements with different id values or with no id attribute,
ensure that all basicRegistry elements have an id attribute set to the same value.
Known issues
A User Input Required window opens when you migrate application configuration
When you migrate application configuration, a User Input Required window opens that states that
application publishing requires the applicationMonitor updateTrigger attribute to be set to mbean in the
server configuration file. The prompt asks if you want to set the attribute in the server configuration. You
can safely select No because the migration tool adds the necessary settings to the generated
configuration.
The hostAlias element receives an XML Problem warning

After you migrate server configuration, the Markers pane might contain one or more XML Problem
warnings about hostAlias elements, which are child elements of the virtualHost element. The warning
states:
cvc-complex-type.2.4.d: Invalid content was found starting with element hostAlias.
No child element is expected at this point. server.xml
The hostAlias element was introduced in V8.5.5.2 of the WebSphere Application Server Liberty profile.
Previous versions of the Liberty profile server ignore hostAlias elements, and you can ignore the
warning.
An application that runs on the V8.5.5.2 Liberty profile does not persist session
information in Mozilla Firefox
After you migrate configuration for applications that require multiple cookies to the V8.5.5.2 Liberty
profile, session information might be lost when you use the application in Mozilla Firefox. When the
session information is lost, the values are set to null and Firefox displays an error message. This problem
occurs because Firefox and the Liberty profile server use the same cookie names for the application.
To resolve the problem, add the cookieName="JESSIONSID2" attribute to the httpSession element in the
Liberty profile migratedConfig/context.xml file.
46
Appendix A. Cloud migration rules

The Cloud Migration Tool identifies application issues that must be changed when you move an
application to Liberty for Java on IBM Bluemix or third-party cloud platforms.
Liberty for Java on IBM Bluemix
The following rules are relevant only when migrating applications to Liberty for Java on IBM Bluemix.
v Optimized Java Runtime Environment
v Use Cloudant NoSQL Database service
v Use Data Cache service
v Use MongoDB services
v Use MQ Light service
v Use SQL Database service
WAS Liberty on all cloud platforms
The following rules are relevant when migrating applications to Liberty for Java on IBM Bluemix or to WAS Liberty
on third-party cloud platforms.
v Avoid creating new process instances
v Avoid writing to the local file system
v Capture log information
v Client certificate authentication is not available
v Do not use host names and IP addresses
v Do not use older or non-standard protocols
v HTTP session persistence
v Listening for inbound connections
v Stopping the Liberty server
v Two-phase commit transactions
WAS Liberty on third-party cloud platforms
The following rule is relevant when migrating applications to WAS Liberty on third-party cloud platforms.
v Transport security is terminated at the router
47
48
Appendix B. WebSphere version-to-version migration rules

and quick fixes
The WebSphere Version to Version Application Migration Tool feature evaluates Java code, JSP code and
deployment descriptors as part of its analysis set. This section provides specific details on the rules and
quick fixes that are provided.
WebSphere Application Server conversion rules are included in the following analysis domains:
Figure 19. Analysis domains
Java code review

Under the Java Code Review set of rules, the WebSphere version migration category contains rules for
migrating from WebSphere Application Server Version 5.1, 6.0, 6.1, 7.0, and 8.0 to Version 7.0, 8.0, or 8.5.5.
For more information on a rule, press F1 when viewing the rule in the Software Analyzer Configuration
window or in the results viewer.
Quick fixes are available where possible. Rules without quick fixes flag the rule violations so you can
evaluate their usage and migrate the code manually.
Table 1. V5.1 to V6.0 migration

Rule Name
Quick Fix Action Taken
Check for a behavior change on the

ServletResponse default content type
No
The default content type for HttpServletResponse has

changed from "text/html" to "text/plain" for servlets that do
not set the content type.
Check for behavior change on URLs

containing a plus sign
No
This rule flags calls in Java code that create Uniform Resource
Locators (URL) that contain a plus ("+") character in the URI
that is not part of the query parameters. The plus ("+") is
only reserved in the query string portion of the URL.
Check for expected behavior on

ServletResponse sendRedirect() method
No
The WebSphere Application Server implementation of the

ServletResponse sendRedirect() method omits path
information until the last slash. With a new custom property
this behavior can be corrected.
Do not start threads from code running

within the web container
No
A restriction was added in WebSphere Application Server

V6.0 that code running in the web container is no longer
allowed to start threads.
Use the work manager to schedule asynchronous beans
instead of creating new threads.
49
Table 1. V5.1 to V6.0 migration (continued)

Rule Name
Use leading slash on ServletContext

getResource() and
getResourceAsStream() requests
No
This rule flags calls to the ServletContext.getResource() and

ServletContext.getResourceAsStream() methods where it
cannot easily be determined if the String value passed on the
method contains a leading slash (/) as required by the servlet
specification.
Do not use activity component features

that were removed
No
This rule flags the use of the activity component classes and
interfaces that were removed in WebSphere Application
Server V6.0.
Do not use Ant task features that were

removed
No
This rule flags the use of the Ant task classes and interfaces
that were removed in WebSphere Application Server V6.0.
Do not use asynchronous bean features

that were removed
No
This rule flags the use of the asynchronous bean classes and
Server V6.0.
Do not use object pool features that were No

removed
This rule flags the use of the object pool classes that were
removed in WebSphere Application Server V6.0.
Do not use RAS features that were

removed
No
This rule flags the use of the RAS classes and interfaces that
were removed in WebSphere Application Server V6.0.
Do not use scheduler features that were

removed
No
This rule flags the use of the scheduler classes and interfaces
Do not use security features that were

removed
No
This rule flags the use of the security classes and interfaces
Do not use the EarUtils class that was

removed
No
This rule flags the use of the EarUtils class that was removed
in WebSphere Application Server V6.0.
Do not use setJMSPriority() method that

was removed
No
This rule flags the use of the method, setJMSPriority, from the
interface, com.ibm.websphere.scheduler.MessageTaskInfo.
This method was deprecated in the Websphere Application
Server V6.0 release and was replaced by the method
getJMSPriority.
Do not use user profile features that

were removed
No
This rule flags the use of the user profile classes and
Server V6.0.

Rule Name
Check for behavior change on

EJBContext.setRollbackOnly() method
No
A call to setRollbackOnly under a certain scenario can yield a

different result on WebSphere Application Server releases
prior to V6.0.2.
Do not use Common Connector

Framework features that were removed
No
This rule flags the use of the Common Connector Framework

API packages that were removed in WebSphere Application
Server V6.1.
Do not use the WebSphere Ant

StopServer.setHost() method that was
removed
No
This rule flags the use of the removed method setHost(String

s) in the com.ibm.websphere.ant.tasks.StopServer class.
Use the open source JDOM

implementation instead of the removed
implementation
No
This rule flags the use of the JDOM packages that were
50

Rule Name
Use the open source Mozilla Rhino

implementation instead of the removed
implementation
No
Use the UserRegistry interface instead of No

the CustomRegistry interface
This rule flags the use of the Rhino packages that were
This rule flags the use of the CustomRegistry interface that
was removed in WebSphere Application Server V6.1.

Rule Name
Check for a behavior change in JAX-WS

dynamic port memory requirements
No
This rule flags the use of JAX-WS dynamic ports that are
created using the javax.xml.ws.Service addPort method. This
behavior change can increase memory requirements.
Check the JAXB context factory

initialization class
No
This rule flags the JAXBContext newInstance() method

because the context factory method has changed since earlier
versions of JAXB.
Only use JAX-WS annotations in Java EE No

5 or later
This rule detects the use of JAX-WS annotations in enterprise

projects earlier than Java EE 5.
Do not use the DistributedLockingMap

interface that was removed
No
This rule flags the removed

com.ibm.websphere.cache.DistributedLockingMap interface.
Do not use the InvalidationEvent or

ChangeEvent constructors that were
removed
No
This rule flags the use of the removed constructors in the

classes com.ibm.websphere.cache.InvalidationEvent or
com.ibm.websphere.cache.ChangeEvent. The new constructor
takes an additional field.
Do not use the

No
SequeLinkDataStoreHelper class that was
removed
This rule flags the use of the com.ibm.websphere.rsadapter.

SequeLinkDataStoreHelper class.
Do not use the WebSphere

UserTransactionWrapper class that was
removed
No
Do not use the com.ibm.websphere.servlet.session.

UserTransactionWrapper class because it has been removed.
Store a UserTransaction directly into the HTTP session
without wrapping it in the removed class.
Do not use the

WSConnectJDBCDataStoreHelper class
that was removed
No
This rule flags the use of the com.ibm.websphere.rsadapter.

WSConnectJDBCDataStoreHelper class and the
com.ibm.websphere.rsadapter.
DataStoreHelper.WSCONNECTJDBC_HELPER field that were
removed.
Do not use web services gateway

customization APIs that were removed
No
Do not use web services Customization APIs. The rule flags

the use of the com.ibm.wsgw.beans.* package.
Use Java EE servlet filters instead of

WebSphere Servlet filter class that were
removed
No
Do not use com.ibm.websphere.servlet.filter classes because

they were removed. Use javax.servlet.filter classes instead.
Use the ConnectJDBCDataStoreHelper

class instead of
DataDirectDataStoreHelper class
Yes
Do not use the com.ibm.websphere.rsadapter.

DataDirectDataStoreHelper object because it was removed.
The quick fix changes the code to use
com.ibm.websphere.rsadapter. ConnectJDBCDataStoreHelper
instead.
Appendix B. WebSphere version-to-version migration rules and quick fixes
51

Rule Name
Use MicrosoftSQLServerDataStore helper Yes

class instead of the
MSSQLDataStoreHelper class
Do not use the com.ibm.websphere.rsadapter.

MSSQLDataStoreHelper class because it was removed.
com.ibm.websphere.rsadapter.
MicrosoftSQLServerDataStoreHelper instead.

Rule Name
Check for a behavior change for EJB

presence in a web module
No
This rule flags EJB annotations in Java files if these files are
in a web module with version 2.5 or higher.
Check for a behavior change in

ApplicationException inheritance
No
This rule flags the EJB ApplicationException annotation

which does not have the attribute inherited set. The inherited
attribute was added in EJB 3.1 and changed default behavior
of EJB 3.0 applications.
Check for a behavior change in SOAP

Action set on outbound messages
No
This rule flags JAX-WS Dispatch client applications that may

experience a behavior change in the SOAP Action setting on
outbound messages.

SOAPMessage methods
No
This rule flags calls to the SOAPMessage methods

getSOAPHeader() and getSOAPBody() that now throw an
exception rather than returning null if the respective header
or body is not present.
Check for a behavior change in web

services SOAP fault codes and strings
No
This rule flags applications that retrieves JAX-WS and

JAX-RPC SOAP fault codes and strings because some of the
content changed in Version 8.0.
Check for a behavior change on

EntityManager refresh(Object entity)
method
No
This rule flags the EntityManager.refresh() method because

the behavior of this method has changed.

OpenJPAEntityManager detach(T pc)
method
Yes
This rule flags the OpenJPAEntityManager detach(T pc)

method. The method return type changed to support the 2.0
JPA specification.
The quick fix changes the detach() method to detachCopy().

SipFactory methods
No
This rule flags certain SipFactory methods using a String to,

from, or addr parameter for which there is a behavior
change.
Check for a behavior change on some

Server MBean operations
No
This rule flags the use of changed Server MBean operations

getComponentVersion, getEFixVersion, getPTFVersion,
getExtensionVersion, getVersionsForAllComponents, and
getVersionsForAllEFixesstartTransports.
Do not use the removed Apache SOAP

API
No
This rule flags the use of the removed classes in the

org.apache.soap and com.ibm.soap packages.
Do not use the removed method

getCause() from ServletErrorReport
No
This rule flags the removed getCause() method in the

com.ibm.websphere.servlet.error. ServletErrorReport class.
52

Rule Name
Use the Oracle 11g helper instead of

earlier versions
Yes
This rule flags the use of the Oracle 10g helpers and fields.
Version 8.0 only supports the Oracle 11g JDBC driver and
helper.
The quick fix changes the code to use the Oracle 11g helper
after confirming that the runtime configuration was changed.
Table 5. V8.0 to V8.5.5 migration

Rule Name
Check for a behavior change in JPA

cascade strategy
No
This rule flags projects using JPA entity relationships that use
cascade types PERSIST, MERGE, or ALL because there is a
potential behavior change in WebSphere Application Server
V8.5. There is a corresponding XML rule to detect this
behavior change.
JSP code review

Under the JSP code review set, the WebSphere version migration category has rules described in the
following table. For more information, press F1 when viewing the rule in the results viewer.
Note: JSP pages written in XML syntax (JSP documents) are not supported.
Table 6. Migrating from Version 5.1

Rule Name
Check for behavior change for included

JSP encoding
No
In JSP 2.0, page encoding is done on a per-file basis. This rule

detects the statically included JSP files that have different
page encoding than the parent JSP.
Check for behavior change on the

request.getAttribute() method
No
This rule flags calls to request.getAttribute() in JSP files that

use automatic casting to a String. However in V6, the
request.getAttribute() method returns an Object, not a String.
Check for behavior change on URLs

containing a plus sign
No
This rule flags a URI in a JSP link tag (<a>) or a form action
tag (<form action=...) that contain a plus ("+") character in the
URI but not a part of the query parameters. The plus ("+") is
only reserved in the query string portion of the URL.
Do not use default packages in JSP

import statements
No
As of JSP 2.0, you cannot refer to any classes from the

unnamed (also known as the default) package. This rule
detects JSP Import Directives that contain classes from the
default package.

Rule Name
Do not redefine a taglib prefix using a

different URI
No
This rule flags JSP taglib directives which associate the same
prefix attribute value with different uri attribute values.
53

Rule Name
Do not use Java keywords in JSP and JSF No

expression language elements
This rule flags JSP expression language (EL) elements with

variables names that contain Java keywords or EL reserved
keywords.
XML code review

The XML file review provides rules to detect deployment descriptor and other XML file issues.

Rule Name
Detect bad attributes of the

global-transaction element
Yes
This rule flags an invalid transaction timeout attribute of the

global-transaction element in the ibm-ejb-jar-ext.xml file.
Do not use bean-managed persistence in

EJB 3.0 projects
No
This rule detects the use of bean-managed persistence in EJB

3.0 projects, which is valid in the IBM WebSphere Application
Server V6.1 Feature Pack for Enterprise JavaBeans 3.0 but not
in WebSphere Application Server V7.0.
Use application version 1.4 or lower

when migrating applications from
WebSphere V6.1 or prior
Yes
When migrating from WebSphere Version 6.1 or prior, this

rule flags any application with a version higher than 1.4.
Use the metadata-complete attribute for

Java EE 5 modules without annotations
No
This rule flags Java EE 5 modules that do not have the

metadata-complete attribute set.
Use web module version 2.4 or lower

when migrating applications from
WebSphere V6.1 or prior
Yes
When migrating from WebSphere Version 6.1 or prior, this

rule flags any web module with a version 2.5 or higher which
can cause migration issues.
Use unique EJB 3.0 binding names
No
WebSphere Application Server V6.1 Feature Pack for EJB 3.0

allowed the EJB 3.0 binding file to contain duplicate binding
names. The V7.0 server runtime environment added
uniqueness checks for names used in the EJB 3.0 bindings
file. Applications with uniqueness errors do not start in V7.0
even though the same application worked on the Feature
Pack for EJB 3.0.
This rule validates the EJB 3.0 bindings file to verify binding
name uniqueness. It also validates that class names for
session interfaces and interceptors are fully qualified.

Rule Name

No
54
This rule flags a web.xml file of a Web Module Version 2.5 or

higher if that module contains a .class file which has an EJB
annotation. The .class file must be in a library (a .jar file in
WEB-INF/lib).

Rule Name

ApplicationException inheritance
No
This rule flags EJB ApplicationException definitions in

ejb-jar.xml files which do not have the inherited attribute
set. The inherited attribute was added in EJB 3.1 and changed
the default behavior of EJB 3.0 applications.
Check for a behavior change in Java

Server Faces (JSF) Applications
No
This rule flags the Java Server Faces (JSF) application because
the default implementation for JSF container has changed in
WebSphere V8.0.
Check for a behavior change in JSP

configuration of <is-xml> and
<page-encoding> options
No
This rule flags the <is-xml> and <page-encoding> JSP

configuration options. The JSP specification was clarified with
respect to these configuration options and included JSP files,
and the behavior changed in Version 8.0.
Check for a behavior change in web

services addressing policy
No
This rule flags addressing policy configuration found in the

WSDL definition. The addressing policy was ignored in the
WSDL definition in previous releases. This behavior change
would cause problems only if the the addressing policy in the
packaged WSDL differs in a significant way from the active
configured addressing policy.
Detect validation.xml files
No
This rule flags the existence of XML files named

validation.xml within the project contents. In Java EE 6,
validation.xml became a reserved filename for use by the
Bean Validation API.

Rule Name

cascade strategy
No
This rule flags projects using JPA entity relationships that use
cascade types PERSIST, MERGE, or ALL because there is a
potential behavior change in WebSphere Application Server
V8.5. There is a corresponding Java rule to detect this
behavior change.

MetaModel code generation concerning
ListAttribute
No
This rule flags the persistence.xml file for a behavior change

in JPA MetaModel code generation concerning ListAttribute
in WebSphere V8.5.
File review
The file review rules analyzes issues in files other than Java, XML, JSP in your application.

Rule Name

No
This rule scans JAR files your in WEB-INF/lib folder to see if

any EJB annotations or deployment descriptors are detected.
55
Deprecated features
There are deprecation rules under the Java Code Review, JSP Code Review, and XML File Review
categories. The rules are organized by target release:
v Migration to V7.0 - currently deprecated in V7.0 and removed in V8.0
v Migration to V7.0 and V8.0 - currently deprecated in V7.0 and in V8.0
v Migration to V8.0 - newly deprecated in V8.0
v Migration to V8.5 - newly deprecated in V8.5
Table 13. Java deprecated features - Migration to V7.0

Rule Name
Quick
Fix
Action Taken
Avoid using the deprecated Apache

SOAP API
No
This rule flags references to the org.apache.soap and

com.ibm.soap packages.
Avoid using the deprecated

OracleDataStoreHelper class
Yes
This rule flags the use of the deprecated Oracle data store helper
and field.
The quick fix changes the code to use the Oracle 11g helper after
confirming that the server runtime configuration was changed.
Table 14. Java deprecated features - Migration to V7.0 and V8.0

Rule Name
Quick
Fix
Action Taken
Avoid using the deprecated analyzer

logging system classes
No
This rule flags the use of the deprecated com.ibm.websphere.als

classes.
Avoid using the deprecated Ant

setCompileWithAssert method
Yes
This rule flags the use of the deprecated Ant method

setCompileWithAssert.
The quick fix replaces the method with setJdkSourceLevel.

AppDeploymentController methods
No
This rule flags the use of the application deployment controller

getTaskInfo methods.

AppDeploymentTask methods
Yes
This rule flags the use of the deprecated methods from the
com.ibm.websphere.management.application.
client.AppDeploymentTask class.
The quick fix changes the methods to the recommended
replacements.

application management
installStandaloneRAR method
No
This rule flags the use of the application management

installStandaloneRAR method.

application management
moveModule method
No
This rule flags the use of the application management

moveModule method.

application profile access intent
methods
No
This rule flags the use of deprecated application profile access

intent methods.
Avoid using the deprecated Cache

interface
No
This rule flags the use of the com.ibm.websphere.Cache interface.
56
Table 14. Java deprecated features - Migration to V7.0 and V8.0 (continued)
Rule Name
Quick
Fix
Action Taken

com.ibm.etools.logging utilities
No
This rule detects and flags references to com.ibm.etools.logging

packages that are deprecated.

command manager methods
Yes
This rule flags the use of the deprecated methods in

com.ibm.websphere.management.cmdframework.
CommandMgrInitializer class.
replacements.

ConnectionFactory MBean methods
No
This rule flags the deprecated ConnectionFactory MBean

operations getPoolContents, getAllPoolContents, and
showAllocationHandleList.

ConnectionSpecImpl methods
Yes
This rule flags the deprecated methods from the

com.ibm.websphere.ola.ConnectionSpecImpl class.
The quick fix changes the parameter to the appropriate boolean
value.

Connector Architecture interfaces
No
This rule flags the deprecated Connector Architecture interfaces

com.ibm.websphere.j2c. ConnectionEventListener and
com.ibm.websphere.j2c.ConnectionManager.

distributed locking map field
No
This rule flags the deprecated com.ibm.websphere.cache.

DistributedObjectCache. TYPE_DISTRIBUTED_LOCKING_MAP
field and the removed com.ibm.websphere.cache.
DistributedLockingMap interface.

DumpNameSpace constructor and
fields
No
This rule flags the use of the deprecated constructor and fields
from the com.ibm.websphere.naming.DumpNameSpace class.

DynamicCacheAccessor methods
No
com.ibm.websphere.cache.DynamicCacheAccessor class.
Avoid using the deprecated dynamic

cache methods and fields
No
This rule flags the use of the deprecated methods and fields from
the com.ibm.websphere.cache.CacheEntry and the
com.ibm.websphere.cache.EntryInfo interfaces.
Avoid using the deprecated EJB

persistence createInteraction method
No
This rule flags the use of the com.ibm.websphere.ejbpersistence.

EJBToRAAdapter.createInteraction (javax.resource.cci.Connection
conn) method.

ExtendedJTATransaction method
registerSynchronizationCallbackFor
CurrentTran
No
This rule detects and flags the method

registerSynchronizationCallbackFor CurrentTran from the class
ExtendedJTATransaction.

HttpServlet request/response proxy
classes
No
This rule flags the use of the HttpServletRequestProxy and

HttpServletResponseProxy classes.
Avoid using the deprecated interface

SIBTransmitMessageRequest
Yes
This rule flags the use of the com.ibm.websphere.sib.admin.

SIBTransmitMessageRequest interface.
The quick fix replaces the interface with the
com.ibm.websphere.sib.admin. SIBMessageRequest interface.
Avoid using the deprecated JRas

extension APIs
No
This rule flags deprecated Java reliability, availability, and

serviceability APIs.

LocalHomeAccessor class
No
This rule flags the use of the com.ibm.websphere.ejbcontainer.

LocalHomeAccessor class.
57
Rule Name
management
InvalidDocumentURIException class
Quick
Fix
Yes
Action Taken
This rule flags the use of the
com.ibm.websphere.management.exception.
InvalidDocumentURIException class.
DocumentNotFoundException.

management NestedAdminException
class
No

com.ibm.websphere.management.exception.
NestedAdminException class.

management NotificationConstants
TYPE_AGENT_DISCOVERED field
Yes

NotificationConstants.TYPE_AGENT_DISCOVERED field.

management
removeNotificationListenerExtended
method
No
This rule flags the use of the deprecated

removeNotificationListenerExtended methods from the
com.ibm.websphere.management.AdminService and
com.ibm.websphere.management.AdminClient classes.

management statistics interfaces
Yes

com.ibm.websphere.management.statistics package.
The quick fix replaces references to this field with the

NotificationConstants.TYPE_DISCOVERY_AGENT_FOUND field.
The quick fix changes all references of

com.ibm.websphere.management.statistics to
javax.management.j2ee.statistics and all reference of
MessageBeanStats to MessageDrivenBeanStats.
Avoid using the deprecated methods
from WebSphere SIB MQ classes
Yes
This rule flags the use of the getNpmSpeed() and getStatus()

methods from SIB MQ classes.
replacements.
Avoid using the deprecated naming

properties INITIAL_CONTEXT_
FACTORY_LEGACY field
Yes
This rule flags the use of the com.ibm.websphere.naming.

PROPS.INITIAL_CONTEXT_FACTORY_LEGACY field.
Avoid using the deprecated PMI

Client API
No
This rule flags the use of PMI Client API classes.

PmiConstants fields
No
This rule flags the use of deprecated PmiConstants fields.
The quick fix changes all references to this field to

com.ibm.websphere.naming.
PROPS.INITIAL_CONTEXT_FACTORY.

No
PmiDataInfo getParticipation method

com.ibm.websphere.pmi.PmiDataInfo. getParticipation() method.

dynamic cache
OBJECT_CACHE_GROUP field

com.ibm.websphere.pmi.stat.
WSDynamicCacheStats.OBJECT_CACHE_GROUP field.
Yes
The quick fix changes OBJECT_CACHE_GROUP to

OBJECT_GROUP.
dynamic cache
SERVLET_CACHE_GROUP field
58
No

com.ibm.websphere.pmi.stat.
WSDynamicCacheStats.SERVLET_CACHE_GROUP field.
Rule Name
Quick
Fix
Action Taken

PmiJmxTest methods
No
com.ibm.websphere.pmi.PmiJmxTest class.

MBeanLevelSpec methods
No
This rule flags the use of the deprecated constructors and

methods from the com.ibm.websphere.pmi.stat.MBeanLevelSpec
class.

PmiModuleConfig print method
No

com.ibm.websphere.pmi.PmiModuleConfig. print(PrintWriter)
method.

StatDescriptor methods
No
This rule flags the use of the deprecated constructor and methods
from the com.ibm.websphere.pmi.stat.StatDescriptor class.

statistic classes
No
This rule flags the use of the deprecated classes from the
com.ibm.websphere.pmi.stat package.

WSStats methods
No
com.ibm.websphere.pmi.stat.WSStats interface.

RemoteCommandMgr MBean
No
This rule flags the deprecated RemoteCommandMgr MBean.
Avoid using the deprecated resource

adapter classes and interfaces
No
This rule flags the use of the deprecated resource adapter classes
and interfaces.

adapter fields
No
This rule flags the use of the deprecated resource adapter fields.

adapter methods
No
This rule flags the use of the deprecated resource adapter

methods.
Avoid using the deprecated runtime

ServerName methods
No
This rule flags the use of methods deprecated from the

com.ibm.websphere.runtime.ServerName class.
Avoid using the deprecated scheduler No

MessageTaskInfo methods
com.ibm.websphere.scheduler.MessageTaskInfo class.

Scheduler methods
No
This rule flags the use of the deprecated createBeanTaskInfo() and

createMessageTaskInfo() methods from the
com.ibm.websphere.scheduler.Scheduler class.
Avoid using the deprecated security

authentication exception classes
No
This rule flags the use of the deprecated exception classes

com.ibm.websphere.security.auth. MapCredentialFailedException
and com.ibm.websphere.security.auth.
MapCredentialNotSupportedException.

authentication WSPrincipal
getCredential method
No
This rule flags the use of the deprecated getCredential() method

from the com.ibm.websphere.security.auth.WSPrincipal class.

printStackTrace() methods
No
This rule flags the use of the deprecated printStackTrace()

methods from the com.ibm.websphere.security.
WSSecurityException and com.ibm.websphere.security.auth.
WSLoginFailedException classes.

LoginHelper class
No

com.ibm.ws.security.util.LoginHelper class.
Avoid using the deprecated servlet

cache classes
No
This rule flags the use of the deprecated servlet cache classes.

cache IdGenerator methods
No
This rule flags the use of the deprecated methods initialize() and
getSharingPolicy() from the
com.ibm.websphere.servlet.cache.IdGenerator class.
59
Rule Name
Quick
Fix
Action Taken

cache MetaDataGenerator initialize
method
No
This rule flags the use of the deprecated initialize() method from
the com.ibm.websphere.servlet.cache. MetaDataGenerator class.

SIMediationBeanMessageContext
interface
No

com.ibm.websphere.sib.mediation.
messagecontext.SIMediationBeanMessageContext interface.

SIMessageContextException class
Yes

com.ibm.websphere.sib.mediation.handler.
SIMessageContextException class.
The quick fix changes the code to use MessageContextException
instead.

TransactionControl interface
No

com.ibm.ws.extensionhelper. TransactionControl interface.
Avoid using the deprecated UDDI

Version 2 interfaces
No
This rule flags the use of UDDI Version 2 related packages.

UNTGenerateCallback methods
Yes
com.ibm.websphere.wssecurity.
callbackhandler.UNTGenerateCallback class.
replacements.

WASProduct class
No
This rule flags the deprecated

com.ibm.websphere.product.WASProduct class was used to get
product installation information and history.
Avoid using the deprecated web

container custom extension classes
No
This rule flags the deprecated web container custom extension

classes from the com.ibm.servlet package.

WebContainer MBean operations
No
This rule flags references to the deprecated WebContainer MBean

operations startTransports, stopTransports, and
restartWebApplication.

WebSphere Ant class
ModuleValidator
No
This rule flags the use of the deprecated WebSphere Ant class
com.ibm.websphere.ant.tasks. ModuleValidator.

WebSphere Studio tools runtime
classes
No
This rule flags the use of the deprecated WebSphere Studio tools
runtime classes from the com.ibm.webtools.runtime package.

WSAddressing for JAXWS 2.0 classes
No
This rule flags the deprecated WSAddressing for JAXWS 2.0

classes from the com.ibm.websphere.wsaddressing.jaxws package.

WsnBatchResult fields
Yes
This rule flags use of deprecated fields from the

com.ibm.websphere.naming.WsnBatchResult class.
The quick fix changes the fields to the recommended
replacements.
60

Rule Name
Quick
Fix
Action Taken
Avoid extending the

AppDeploymentTask class
No
This rule flags any class that extends

client.AppDeploymentTask.

AppConstants fields
No
This rule flags the use of the deprecated fields from the
com.ibm.websphere.management.application. AppConstants class.

AppManagementBaseFactory
methods
No
AppManagementBaseFactory class.

com.ibm.websphere.product classes
No
This rule flags the deprecated classes from the

com.ibm.websphere.product packages.
Avoid using the deprecated elements

in the EditionInfo class
No
This rule flags the use of the deprecated elements from the
com.ibm.websphere.management.application. EditionInfo class.
Avoid using the deprecated elements

in the IFilterConfig interface
No
This rule flags the use of the deprecated elements from the
com.ibm.websphere.servlet.filter. IFilterConfig interface.
Avoid using the deprecated field in

the AppDeploymentController class
No
This rule flags the use of the deprecated field taskHelperSuffix

from the class com.ibm.websphere.management.application.
client.AppDeploymentController.
Avoid using the deprecated IRequest

isStartAsync() method
No
This rule flags the use of the deprecated method isStartAsync()

from the interface com.ibm.websphere.servlet.request.IRequest.

WASDirectory methods and fields
No

com.ibm.websphere.product.WASDirectory methods and related
fields.

WebSphere Studio Application
Developer Integration Edition
libraries
No
This rule flags the use of the deprecated WebSphere Studio

Application Developer Integration Edition libraries.

Rule Name
Quick
Fix
Action Taken
Avoid using the deprecated Common No

Event Infrastructure packages
This rule flags APIS from the deprecated com.ibm.events

packages.

WSSecurityHelper
getLTPACookieFromSSOToken
method

com.ibm.websphere.security.WSSecurityHelper
getLTPACookieFromSSOToken method.
Yes

Yes
WSSecurityHelper revokeSSOCookies
method

com.ibm.websphere.security.WSSecurityHelper revokeSSOCookies
method.
61
Table 17. JSP file deprecated features - Migration to V7.0 and V8.0
Rule Name
Quick
Fix
Avoid using the deprecated JSP <tsx> No

tags
Action Taken
This rule flags the use of the deprecated <tsx> tags in JSP files.
Table 18. XML file deprecated features - Migration to V7.0 and V8.0
Rule Name
Quick
Fix
Action Taken

method-level access intent for entity
beans
No
This rule flags the use of method-level access intent on entity

beans.
Avoid using the deprecated reload

attributes of the IBM deployment
descriptor extensions
No
This rule flags the deprecated reloadInterval and

reloadingEnabled attributes of the IBM deployment descriptor
extensions, including both the WAR file extension
(WEB-INF/ibm-web-ext.xmi) and the application extension
(META-INF/ibm-application-ext.xmi).
62
Appendix C. WAS Liberty migration rules

The WAS Liberty rules are used in in the report to give a high-level evaluation of the application
technologies and in the analysis to provide migration evaluation details.
This section provides information on the technologies included in the the report and the rules in the
detailed analysis.
Rules for the Application Evaluation Report

The tool identifies Java technologies used in applications and identifies the WebSphere Application Server
platforms where each technology can run. This section shows the technologies that the report can detect.
Some of the rules are duplicated but have the clarification provided by application. This clarification
indicates that the application uses the technology and an implementation of the technology is packaged
with the application.
Table 19. Java technologies in WebSphere Application Server platforms
Web services technologies
Bluemix
Liberty Core
Liberty
profile
Full profile
Java API for RESTful Web Services (JAX-RS) - JSR 311
Implementing Enterprise Web Services - JSR 109
Java API for XML-Based Web Services (JAX-WS) - JSR

224
Java API for XML-Based Web Services (JAX-WS) Provided by application - JSR 224
Java Architecture for XML Binding (JAXB) - JSR 222
Web Services Metadata for the Java Platform - JSR 181
Java API for XML-based RPC (JAX-RPC) - JSR 101
Java API for XML-based RPC (JAX-RPC) - Provided by U

application - JSR 101
Java API for WSDL (JWSDL)
Java APIs for XML Messaging - JSR 67

SOAP with Attachments API for Java (SAAJ) - JSR 67
U
U
Java API for XML Registries (JAXR) - JSR 93
Web Services Notification (WS-Notification)
Web Services Atomic Transaction (WS-AT)
Web Services Business Activity (WS-BA)

Web application technologies
Bluemix
Liberty Core
Liberty
profile
Full profile
Java API for JSON Processing (JSON-P) - JSR 353
Java Servlet - JSR 315
JavaServer Faces (JSF) - JSR 314
JavaServer Pages/Expression Language (JSP/EL) - JSR

245
63
Table 19. Java technologies in WebSphere Application Server platforms (continued)

Liberty Core
Liberty
profile
Full profile
Standard Tag Library for JavaServer Pages (JSTL) - JSR U

52
Java API for WebSocket - JSR 356
Liberty Core
Liberty
profile
Web application technologies
Bluemix

Enterprise application technologies
Bluemix
Full profile
Batch Applications for the Java Platform - JSR 352
Concurrency Utilities for Java EE 1.0 - JSR 236
Contexts and Dependency Injection for Java (Web

Beans) - JSR 299
Dependency Injection for Java - JSR 330
Bean Validation - JSR 303
Enterprise JavaBeans (EJB) 2.x and 1.x - JSR 318

Enterprise JavaBeans (EJB) Lite subset - JSR 318
Remote Enterprise JavaBeans (EJB) - JSR 318
Enterprise JavaBeans (EJB) Timers - JSR 318
Interceptors - JSR 318
Java Connector Architecture (JCA) - JSR 322
Java Persistence API (JPA) - JSR 317 or 338
Common Annotations for the Java Platform - JSR 250
Java Message Service (JMS) API - JSR 914
Java Message Service (JMS) API - Provided by

application - JSR 914
Java Transaction API (JTA) - JSR 907
JavaMail - JSR 919
JavaMail - Provided by application - JSR 919
Liberty Core
Liberty
profile
Full profile

Management and security technologies
Bluemix
Java Authentication Service Provider Interface for

Containers (JASPIC) - JSR 196
Java Authorization Contract for Containers (JACC) JSR 115
Java EE Application Deployment - JSR 88

J2EE Management - JSR 77
U
U

Java EE-related specifications in Java SE
Bluemix
Liberty Core
Liberty
profile
Full profile
Java API for XML Processing (JAXP) - JSR 206
Java Database Connectivity (JDBC) - JSR 221
64
Table 19. Java technologies in WebSphere Application Server platforms (continued)

Java EE-related specifications in Java SE
Bluemix
Liberty Core
Liberty
profile
Full profile
Java Management Extensions (JMX) - JSR 255
JavaBeans Activation Framework (JAF) - JSR 925
Streaming API for XML (StAX) - JSR 173

Blueprint-related technologies
Bluemix
Liberty Core
Liberty
profile
Full profile
Blueprint Container
Blueprint transactions
Blueprint JPA
Blueprint security
Blueprint resource references

Web-related technologies in OSGi bundles
Bluemix
Liberty Core
Liberty
profile
Full profile
Web Application Bundles
Java Naming and Directory Interface (JNDI)
JavaServer Pages (JSP)
Standard Tag Library for JavaServer Pages (JSTL)
JavaServer Faces (JSF)
Java API for RESTful Web Services (JAX-RS)
Liberty Core
Liberty
profile
Full profile

Other enterprise technologies
Bluemix
EJB Bundles
Remote Service Admin
Repository Service
SCA Configuration Type Specification
Service Component Architecture (SCA) - IBM APIs
Service Component Architecture (SCA)
Service Component Architecture (SCA) - Oasis

provided by application
Service Component Architecture (SCA) - Oasis

Service Component Architecture (SCA) - OSOA
U
U
Service Component Architecture (SCA) - OSOA

Service Component Architecture (SCA) - Tuscany
U
U
U
Service Component Architecture (SCA) - Tuscany
Session Initiation Protocol (SIP)
65
Rules for migrating applications to Liberty

The WebSphere Classic to WAS Liberty migration rules identify application issues that require changing
when you move an application from the full profile to WAS Liberty, WAS Liberty Core, or Liberty for
Java on IBM Bluemix or Liberty on third-party cloud platforms.
Table 20. WAS Liberty migration rules
WebSphere Application Server full profile to Liberty profile rules
The tool scans applications for the following issues when migrating from the WebSphere Application Server full
profile to all Liberty editions.
v Behavior difference for web service host name validation
v CDI OpenWebBeans APIs are unavailable
v JAR files in subfolders are not loaded
v Namespace values in application.xml must be consistent with descriptor version
v Namespace values in ejb-jar.xml must be consistent with descriptor version
v Namespace values in ra.xml must be consistent with descriptor version
v Namespace values in web.xml must be consistent with descriptor version
v OSGi bundles might need explicit package imports
v Review differences in the WebSphere z/OS Optimized Local Adapters API
v Review differences in WebSphere MBeans
v Review use of the dynamic cache service
v Review use of the javax.activation.DataHandler object
v SCA is unavailable
v SOAP over Java Message Serivce (JMS) is unavailable
v Some third-party APIs are unavailable on the Liberty profile
v Some WebSphere APIs are unavailable on the Liberty profile
v Some WebSphere z/OS Optimized Local Adapters APIs are unavailable
v The Activity Session service is unavailable
v The Apache Axis2 API is unavailable
v The persistence.xml file must be in a specification-recognized location
v The use of java.sql.Driver and java.sql.DriverManager interfaces requires configuration
v The use of system provided Apache Aries APIs requires configuration
v The use of system provided Apache CXF WS-Security APIs requires configuration
v The use of system provided Apache OpenJPA APIs requires configuration
v The use of system provided Apache Wink APIs requires configuration
v The use of system provided Eclipse Equinox APIs requires configuration
v The use of the WebSphere XPath, XQuery, and XSLT API require configuration
v The WebSphere Application Profiling API is unavailable
v The WebSphere Asynchronous Beans API was superseded by a newer implementation
v The WebSphere Batch API and SPI are unavailable
v The WebSphere Common Exception APIs are unavailable
v The WebSphere EJB Query API is unavailable
v The WebSphere i18n API and SPI are unavailable
v The WebSphere Runtime API is unavailable
v The WebSphere Scheduler API was superseded by a newer implementation
v The WebSphere SDO API is unavailable
v The WebSphere Servlet API has been superseded by a newer implementation
v The WebSphere Session Initiation Protocol (SIP) API is unavailable
v The WebSphere Startup Beans Service API has been superseded by a newer implementation
66
Table 20. WAS Liberty migration rules (continued)

WebSphere Application Server full profile to Liberty profile rules
v The WebSphere web services APIs are unavailable
v The WebSphere Work Area API and SPI are unavailable
v Use the default InitialContext JNDI properties
v Web Services Atomic Transaction (WS-AT) is unavailable
v Web Services Business Activity (WS-BA) is unavailable
v Web Services Notification (WS-Notification) is unavailable
Java Technology Support for WAS Liberty
The following rules are relevant when migrating applications to all editions of the Liberty profile.
v Entity Enterprise JavaBeans (EJB) are unavailable
v EXtensible Stylesheet Language (XSTL) 2.x is unavailable
v Java API for XML Registries (JAXR) is unavailable
v Java API for XML-based RPC (JAX-RPC) is unavailable
v Java APIs for XML Messaging (JAXM) is unavailable
v Java EE Application Deployment API is unavailable
v Java Portlet is unavailable
v JavaServer Faces (JSF) 1.1/1.2 compatibility
v Session Initiation Protocol (SIP) Servlet API is unavailable
v Spring applications might fail to run from a non-expanded WAR file
v The getRealPath() method returns null from a non-expanded WAR file
v Web Services Notification (WS-Notification) is unavailable
Java Technology Support for WAS Liberty Core
The following rules are relevant only when migrating applications to Liberty Core.
v Asynchronous method invocations for Enterprise JavaBeans (EJB) are unavailable
v Enterprise JavaBeans (EJB) 1.x/2.x is unavailable
v J2EE Management API is unavailable
v Java API for WSDL (JWSDL) is unavailable
v Java API for XML-Based Web Services (JAX-WS) is unavailable
v Java Authentication Service Provider Interface for Containers (JASPIC) API is unavailable
v Java Authorization Contract for Containers (JACC) API is unavailable
v Java Connector Architecture (JCA) API is unavailable
v Java EE Application Client is unavailable
v Java Message Service (JMS) is unavailable
v Message-Driven Beans (MDB) are unavailable
v Remote interfaces for Enterprise JavaBeans (EJB) are unavailable
v Timer service for Enterprise JavaBeans (EJB) is unavailable
v Web Services Metadata for the Java Platform is unavailable
67
Table 21. WebSphere Classic to WAS Liberty Java EE 6 differences

WebSphere Classic to WAS Liberty Java EE 6 differences
This category contains rules that help analyze Java EE 6 differences between WebSphere Classic and WAS Liberty.
v The use of system provided Apache OpenJPA APIs requires configuration
v The use of system provided Apache Wink APIs requires configuration
Java EE 7 behavior differences

When moving from Java EE 6 to Java EE 7, there might be some behavior differences in your application
because of implementation changes and specification clarifications. In WAS Liberty, you are not required
to move to the next Java EE level and can continue to use the existing Java EE 6 features.
Table 22. WebSphere Java EE 7 differences
CDI 1.2
This category contains rules that help migrate from CDI 1.0 to CDI 1.2.
v CDI recognizes implicit bean archives
v CDI scans for implicit beans when there is no beans.xml file
v Check for a valid schema in beans.xml
v Do not use the OpenWebBeans schema for beans.xml
v The openwebbeans.properties file is not used
JAX-RS 2.0
This category contains rules that help migrate to JAX-RS 2.0.
v @Local JAX-RS interfaces must be implemented
v Check media types by using the isReadable and isWriteable methods instead of the @Consumes and @Produces
annotations
v Configuration is required to use SSL in JAX-RS 2.0
v org.codehaus.jackson packages are not available
v Packaging Apache Wink APIs with your application might require application changes
v The Apache Wink APIs are not available
v The Apache Wink Client APIs are not available
v The com.ibm.websphere.jaxrs.server.IBMRestFilter class is no longer supported
v The org.apache.wink.client.handlers.LtpaAuthSecurityHandler class is no longer supported
v The org.apache.wink.common.model.multipart package is not available
JMS Client 2.0
This category contains rules that help migrate from JMS Client 1.1 to JMS Client 2.0.
v Check for a behavior change on message priority and the NoLocal attribute
v Check for a behavior change on setClientID and createDurableSubscriber methods
68

WebSphere Java EE 7 differences - OpenJPA to EclipseLink JPA
This category contains rules that help migrate Java Persistence applications using JPA 2.0 based on OpenJPA to JPA
2.1 based on EclipseLink. Migrating from JPA 2.0 to JPA 2.1 is optional. The Java EE 6 JPA 2.0 feature is compatible
with the other Java EE 7 features.
v All entities must have a primary key
v Annotated getter methods must have a setter method
v Attributes with automatically generated values require configuration
v Disable the persistence unit second-level cache
v Do not use OpenJPA providers in the persistence.xml file
v ElementCollection annotations must be accompanied by a defined Column annotation
v Embeddable classes cannot have an Id annotation when referenced by an EmbeddedId annotation
v Embedded classes must be annotated as embeddable
v Entity objects with constructors must also have a default constructor
v java.util.Locale attributes must be converted
v JoinColumn annotations must be used with relationship mappings
v OpenJPA and WebSphere JPA configuration properties must be migrated
v OrderColumn annotations are not supported on Set attributes
v Mapping files are not processed during OpenJPA to EclipseLink migration
v org.apache.openjpa packages are not available
v Private accessor methods must have a Transient annotation
v Remove the Temporal annotation for some java.sql attributes
v Replace OpenJPA @PersistentCollection annotation with @ElementCollection and @Column
v Replace the Temporal annotation with a Converter annotation for some java.sql attributes
v The openjpa.jdbc.Schema configuration property must be migrated to orm.xml
v Unannotated collection attributes require a Transient annotaion
v Unannotated entity attributes require a Transient annotation
v Validate IN expression syntax with a collection-valued input parameter
69
70
Appendix D. Java SE version migration

Under the Java Code Review set of rules, Java SE Migration category contains rules for migrating from
J2SE 1.4, J2SE 5.0, Java SE 6, or Java SE 7. Java migration targets are Java SE 6, 7, and 8.
The Sun to IBM Java compatibility impacts category provides a set of rules to migrate Sun APIs that are
not available on the IBM Java Runtime Environment. Where possible, the rules migrate the code to use
javax.net or com.ibm.net.ssl classes.
The specific rules selected depends on your selection of the source Java Runtime Environment that your
application previously used and the version of WebSphere you are migrating to. For WebSphere
Application Server V8.5.5, you can choose either Java SE 6 or Java SE 7 as your target. For WAS Liberty
V8.5.5, you can choose either Java SE 6, 7, or 8.
Quick fixes are available where possible. Rules without quick fixes flag the rule violations so you can
evaluate their usage and migrate the code manually if needed.
J2SE 5.0 compatibility impacts

Table 23. J2SE 5.0 compatibility impacts
Rule Name
Check for JAXP API usage compatibility
No
The JAXP APIs used in JRE 1.4.2 might have compatibility

issues when used in JRE 5. This rule detects the import of
any JAXP-related packages so that you can check the usage.
Check for JAXP

EntityResolver.resolveEntity() exception
compatibility
No
JAXP EntityResolver.resolveEntity(String, String) now throws

the exception, IOException, in addition to SAXException. This
rule detects the missing IOException.
Check for new JAXP DOM APIs
No
New JAXP DOM APIs where added to the following

interfaces:
v org.w3c.dom.Attr
v org.w3c.dom.Document
v org.w3c.dom.DOMImplementation
v org.w3c.dom.Element
v org.w3c.dom.Entity
v org.w3c.dom.Node
v org.w3c.dom.Text
This rule detects classes that implement any of these
interfaces and flags them so that the new interfaces can be
added.
Check Java Object Serialization

compatibility
No
Serialization in not consistent between Java 1.4 and Java 5.0.

This rule detects the classes that implement
java.io.Serializable without a serialVersionUID field.
Do not make direct references to

IBMJSSEFIPS provider classes
No
The IBMJSSEFIPS provider has been included in the

IBMJSSE2 support. References to the classes of the previous
provider, com.ibm.fips.*, must be removed.
This rule detects the use of any reference to com.ibm.fips
packages.
71
Table 23. J2SE 5.0 compatibility impacts (continued)

Rule Name
Do not use APIs from com.ibm.net.ssl

packages
Yes
The classes and interfaces in the com.ibm.net.ssl package

have been replaced by classes and interfaces in the
javax.net.ssl package. This rule detects the use of any
reference to com.ibm.net.ssl packages.
The quick fix changes package names com.ibm.net.ssl to
javax.net.ssl.
Do not use APIs from sun.* packages
No
Some APIs in the sun.* packages changed in JRE 5 and have

compatibility issues with JRE 1.4.2. These APIs are not
intended for use by developers. This rule detects the use of
any reference to sun.* packages.
Do not use JAXP 1.1 internal classes
No
Internal JAXP classes changed. Do not use these internal

classes in these packages:
1. org.apache.crimson.*
2. org.apache.xml.*
3. org.apache.xalan.*
4. org.apache.xpath.*
5. org.apache.xalan.xsltc.*
This rule detects the use of these packages and flags them.
Do not use JAXP 1.1 package names in

string literals
No
Some of the implementation package names changed

between JAXP 1.1 and JAXP 1.3. This rule detects JAXP 1.1
package names used in string literals.
Do not use removed IBMJSSE APIs
No
In the conversion from IBMJSSE to IBMJSSE2 two of the JSSE

classes were removed. This rule detects the use of any
reference to com.ibm.jsse. KeyManagerFactoryParametersSpec
and com.ibm.jsse.SSLContext. Since com.ibm.net.ssl.
KeyManagerFactoryParametersSpec was migrated to
com.ibm.jsse. KeyManagerFactoryParametersSpec and then
removed from use, com.ibm.net.ssl.
KeyManagerFactoryParametersSpec is also detected with this
rule.
Do not use the Java reserved word enum No
Beginning in Java 5.0, enum is a reserved Java type and

cannot be used as a variable name any longer. If your code
uses variables named enum, they must be renamed. This rule
detects variables and arguments named enum.
Use the BigDecimal toPlainString()

No
method explicitly when deriving a string
value
The BigDecimal toString() method behaves differently than in

earlier versions. J2SE 5.0 added toPlainString() to BigDecimal,
which behaves like the toString() method in earlier versions.
This rule detects the implicit use of the toString() method in a
class.
Use the BigDecimal toPlainString()

method instead of the toString() method
The BigDecimal toString() method behaves differently than in

earlier versions. J2SE 5.0 added toPlainString() to BigDecimal,
which behaves like the toString() method in earlier versions.
Yes
The quick fix changes toString to toPlainString.
72
Table 23. J2SE 5.0 compatibility impacts (continued)

Rule Name
Use the IBMJSSE2 Provider
Yes
In the conversion from IBMJSSE to IBMJSSE2, the providers,

IBMJSSEProvider and JSSEProvider, are replaced by
IBMJSSEProvider2. This rule detects the use of any reference
to com.ibm.jsse.IBMJSSEProvider and
com.ibm.jsse.JSSEProvider classes.
The quick fix changes the reference to
com.ibm.jsse2.IBMJSSEProvider2.
Java SE 6 compatibility impacts

Table 24. Java SE 6 compatibility impacts
Rule Name
Check exception logic for calls to

EventHandler
No
In Java SE 6, the EventHandler constructor and create()

methods require non-null parameters to be passed. This rule
flags the constructor and create() method calls so that you
can verify your logic handles a NullPointerException
properly.
Check for Duration and

XMLGregorianCalendar equals()
compatibility
No
Detect the use of Duration and XMLGregorianCalendar

equals() method. Java 6 now returns false if the parameter
passed is null. The exception, NullPointerException, was
thrown previously.
Check for new methods on Java SQL

interfaces
No
The java.sql.Wrapper interface was added as a superinterface

to several Java SQL interfaces. When you move to Java 6,
missing methods must be added to classes that implement
the interfaces that added java.sql.Wrapper.
Check for the

OverlappingFileLockException for the
FileChannel lock() method
No
In Java SE 6, the FileChannel.lock() method now throws

OverlappingFileLockException. This rule flags the lock()
method calls without a catch block for
OverlappingFileLockException or without a throws
declaration for OverlappingFileLockException on the method.
Remove use of double slashes in JMX

ObjectName elements
No
Detect the use of the double-slash character string ("//") in

JMX ObjectNames.

Rule Name
Check for a behavior change for an

empty TreeSet add and TreeMap put
methods
No
This rule flags the use of java.util.TreeSet or

java.util.TreeMap. Depending on the configuration of the rule,
either the constructor or the add()/put() methods of these
classes will get flagged. A new behavior is added in Java 7
for these methods.
Check for a behavior change for AWT

Exception Handler
No
This rule flags the string literal sun.awt.exception.handler.

A new exception handling mechanism is added in Java 7.
73
Table 25. Java SE 7 compatibility impacts (continued)

Rule Name
Check for a behavior change for File

setReadOnly, setWritable and canWrite
methods
No
This rule flags the methods java.io.File setReadOnly(),

setWritable(boolean arg) and setWritable(boolean arg,
boolean user). A new behavior is added in Java 7 for these
methods.
Check for a behavior change for

URLConnection, HttpURLConnection
getInputStream method
No
This rule flags the getInputStream() method on

URLConnection or HttpURLConnection. This method has a new
behavior in Java 7.

DatagramChannel send, receive, and
connect methods
No
This rule flags calls to the

java.nio.channels.DatagramChannel send, receive, and
connect methods that have a new behavior in Java 7.
Check for a behavior change on the

isLowerCase and isUpperCase methods
No
This rule flags the isLowerCase and isUpperCase methods.

There is a very slight chance that a behavior change in these
methods could affect your application.
Check for a behavior change on Locale

getDefault method
No
This rule flags calls to the java.util.Locale getDefault()

method as it has a new behavior.

MouseEvent getButton method
No
This rule flags instances of the java.awt.event.MouseEvent

getButton() method as it has a new behavior.

ThreadGroup setMaxPriority method
No
This rule flags the method setMaxPriority on a ThreadGroup

object. The method behavior has changed in JDK 7.
Check for a behavior change on Toolkit

getPrintJob method
No
This rule flags instances of the java.awt.Toolkit

getPrintJob(...) method as it has a new behavior.
Check for a behavior change on Window No

setBackground method
This rule flags calls to the java.awt.Window setBackground()

method because its behavior changed by throwing a new
exception.
Check for classes implementing the

TypeVisitor interface
No
This rule flags classes implementing the

javax.lang.model.type.TypeVisitor interface. In Java SE 7, a
new method was added to this interface.
Check for new methods on JDBC

interfaces
No
This rule detects classes that implement the JDBC interfaces

that added new methods. The interfaces include
java.sql.Connection, java.sql.Driver, java.sql.Statement,
and javax.sql.CommonDataSource.
Do not define methods declared as final

in java.lang.Throwable
No
This rule detects class that extend java.lang.Throwable that

implement methods addSuppressed and getSuppressed
which were added as new final methods in Java 7.
Do not override the Path2D

getPathIterator methods
No
This rule flags the Path2D getPathIterator methods. These

methods are now marked final in Java 7.
Do not use removed class

XSLTProcessorApplet
No
This rule detects the use of the class

org.apache.xalan.client.XSLTProcessorApplet. This class
has been removed from JDK 7 release.
74

Java 8 is supported only on the Liberty profile. You can select these rules when migrating to the Liberty
profile.
Rule Name
Behavior change in exceptions thrown

when setting AWT focus traversal keys
No
In Java 8, the java.awt.Component setFocusTraversalKeys

and the java.awt.KeyboardFocusManager
setDefaultFocusTraversalKeys methods throw
ClassCastException instead of IllegalArgumentException if
any passed keystroke object is not an AWTKeyStroke.
Behavior change in month name

formatting for some languages
No
In Java 8, when formatting date-time values using the

DateFormat and SimpleDateFormat classes, context-sensitive
month names are supported for languages that have different
date formatting and standalone forms of month names. You
might see a difference in the month name returned in strings
formatted by the DateFormat or SimpleDateFormat classes or
by methods on the DateFormatSymbols class.
Behavior change in most

Collection.removeAll and
Collection.retainAll implementations
No
Prior to Java 8, most implementations of

Collection.removeAll(Collection) and
retainAll(Collection) return false and ignore a null
parameter if the collection itself is empty. In Java 8,
collections throw a NullPointerException if null is provided
as the parameter.
Behavior change in new instance

creation for non-public interfaces
No
In Java 8, a code change is required to create a proxy instance

for non-public interfaces located in a different package using
the Proxy.getProxyClass and Constructor.newInstance
methods.
Behavior change in rounding in

NumberFormat and DecimalFormat
format methods
No
In Java 8, the rounding behavior of the NumberFormat and

DecimalFormat format methods changed to match the
rounding of the binary representation of the number.
Behavior change in the BigDecimal

stripTrailingZeros method for a zero
value
No
Java 8 introduces a behavior change when

java.math.BigDecimal stripTrailingZeros operates on a
zero value with a nonzero scale.
Behavior change in the construction of

dynamic proxy classes
No
In Java 8, calling
java.lang.reflect.Proxy(InvocationHandler) with a null
parameter throws a NullPointerException. Prior to Java 8,
the constructor returns a proxy, but any method calls on that
proxy throw a NullPointerException.
Check for classes that implement the

TypeVisitor interface
No
Java 8 added a new method to the

javax.lang.model.type.TypeVisitor interface. This rule flags
classes that implement this interface.
DatagramPacket constructor with

SocketAddress no longer declares
SocketException
No
In Java 8, java.net.DatagramPacket constructors were

changed to remove the SocketException declaration. This rule
flags java.net.DatagramPacket constructors that accept a
java.net.SocketAddress argument when the constructors are
within a try block that catches either a
java.net.SocketException or its superclass
java.io.IOException.
Differences in class loading for JAXP

service providers
No
Java 8 includes Java API for XML Processing (JAXP) 1.6,

which handles class loading for service providers differently
than previous versions.
java.lang.Thread
stop(java.lang.Throwable) is disabled
No
In Java 8, the java.lang.Thread.stop(java.lang.Throwable)

method is disabled.
75
Table 26. Java SE 8 compatibility impacts (continued)

Rule Name
MBean and MXBean interfaces must be

public
Yes
Java 8 enforces the requirement that MBean and MXBean

management interfaces be public. Non-public interfaces are
not allowed to expose the management functionality. This
specification requirement was not enforced in Java 7 and
prior versions.
New methods in
java.util.concurrent.ConcurrentHashMap
No
In Java 8, the ConcurrentHashMap class introduced over 30

new methods. If you extend the
java.util.concurrent.ConcurrentHashMap class, your class
might need changes.
The mechanism to select a locale service

provider changed
No
In Java 8, the mechanism to select a locale service provider

changed. A new method in the LocaleServiceProvider class
allows implementations to determine whether the given
locale is supported.
Oracle to IBM compatibility impacts

Run the following rules when you are migrating your application from an Oracle Java Runtime
Environment to an IBM Java Runtime Environment. If you are running Liberty profile server using an
Oracle Java Runtime, do not run the quick fixes for these rules.
Table 27. Oracle to IBM compatibility impacts
Rule Name
Detect com.sun.net.ssl.internal packages
No
This rule flags import statements of certain

com.sun.net.ssl.internal packages in Java files that are not
available and should not be used.
Do not use APIs from com.sun.net.ssl

packages
Yes
This rule detects the classes and interfaces in the

>com.sun.net.ssl package have been replaced by classes and
interfaces in the javax.net.ssl package.
Do not use com.sun.org.apache JAXP

internal classes
No
This rule flags internal Sun JAXP classes are not available in
the IBM Java Runtime Environment.
Do not use com.sun.org.apache JAXP

package names in string literals
No
This rule detects com.sun.org.apache JAXP 1.3 package

names that are used in string literals.
Do not use the

Yes
com.sun.net.ssl.internal.ssl.Provider class
This rule flags the class

com.sun.net.ssl.internal.ssl.Provider should be replaced
by com.ibm.jsse.IBMJSSEProvider.
Do not use the com.sun.net.ssl.internal.

www.protocol.https.Handler class
Yes
This rule flags the com.sun.net.ssl.internal.www.protocol.

https.Handler class that should be replaced by
com.ibm.net.ssl.www2.protocol.https.Handler.
Do not use the

com.sun.net.ssl.internal.www.protocol
package
Yes
This rule flags the com.sun.net.ssl.internal.www.protocol

package references that should be replaced by
com.ibm.net.ssl.www2.protocol.
76
Sun internal APIs

Only run the following rules when you are migrating your application from an Oracle Java Runtime
Environment to an IBM Java Runtime that contains the IBM class. For example, the HP-UX and Solaris
Java Runtime Environment that ships with WebSphere Application Server does not contain the class. This
rule is not selected automatically by any rule set.
Table 28. Sun internal APIs
Rule Name
Do not use APIs from the

sun.security.x509 package
Yes
The classes and interfaces in the sun.security.x509 package

are replaced by classes and interfaces in the
com.ibm.security.x509 package on some operating systems.
77
78
Appendix E. Third-party application server migration rules

and quick fixes
WebLogic Server rules and quick fixes
The WebLogic to WebSphere Application Migration Tool feature evaluates Java code, JSP code,
deployment descriptors, and web services deployment descriptors as part of its analysis set.
When you select the WebLogic Application Migration rule set, relevant WebLogic Server rules,
framework rules, and Java SE rules will be selected. The WebLogic Server specific rules are described in
this section. The Java SE rules are described in Appendix D, Java SE version migration, on page 71. The
Java SE rules selected depend on your source and target Java Runtime Environment configuration when
you choose the rule set. The framework rules are described in Framework migration on page 95.
WebLogic Server Java code review rules

Under the Java Code Review set of rules, the WebLogic to WebSphere code migration category contains
multiple rules. For more information, press F1 when viewing the rule in the Software Analyzer
Configuration window or in the results viewer.
Rule Name
Quick Fix
Action Taken
Do not use BEA Beehive @common

annotations
No
This rule detects @common Javadoc tags that are found in the
migrated BEA Beehive files.
Do not use BEA Beehive @jpf:action

annotations
Yes
This rule detects and migrates @jpf:action Javadoc tags that are
found in the migrated BEA Beehive files.
Do not use BEA Beehive

@jpf:controller annotations
Yes
This rule detects and migrates @jpf:controller Javadoc tags

that are found in the migrated BEA Beehive files.
Do not use BEA Beehive

@jpf:exception-handler annotations
Yes
This rule detects and migrates @jpf:exception-handler Javadoc

tags that are found in the migrated BEA Beehive files.
Do not use BEA NetUI packages
Yes
This rule detects and migrates BEA com.bea.wlw.netui packages.
Detect Apache Beehive packages
No
This rule detects the use of Apache Beehive packages, which

begin with org.apache.beehive.
Do not put EJB classes in default Java No

packages
This rule detects Java classes that define EJBs that are in default
Java packages. WebSphere Application Server does not allow
EJBs in default Java packages.
Do not start threads within the web

or EJB containers
No
This rule detects code within web or EJB modules that starts or
runs threads.
Do not use Apache XMLBeans

packages
No
This rule detects references to the Apache XMLBeans package

org.apache.xmlbeans.
Do not use Commons Logging

system level property
Yes
This rule detects setting the commons logging implementation

class using the system property.
The quick fix removes the entry.
Do not use invalid JPA imports
No
This rule detects the use of specific kodo import statements that
do not have equivalent openJPA imports.
These references are flagged so you can evaluate their usage and
migrate manually.
79
Rule Name
Quick Fix
Action Taken
Do not use JNDI name lookup to

reference the runtime MBean server
No
This rule detects the string literal "java:comp/env/jmx/runtime"

which WebLogic Server provides as the JNDI name for the
runtime MBean server. This lookup does not work on
WebSphere Application Server.
Do not use kodo properties that have No

no openJPA equivalent
This rule detects JPA properties that start with kodo.* in java
files but have no equivalent openJPA values.
Do not use non-mapping

weblogic.apache packages
This rule detects import and code references to classes where the
class package starts with weblogic.apache and the class does not
map to an open source Apache class.
No
You must modify the code to use different classes. See the rule
help for more information.
Do not use non-portable JPA imports
Yes
This rule detects WebLogic Server kodo import statements.

The quick fix replaces them with openJPA equivalent import
statements.
Do not use subclass of EntityManager Yes

or EntityManagerFactory for injected
JPA elements
This rule detects injected JPA PersistenceContext or

PeristenceUnit where the injectable type is a subclass of
EntityManager or EntityManagerFactory.
The quick fix changes the class to use the standard JPA object.
Do not use the WebLogic

No
ApplicationLifecycleListener interface
This rule detects classes that implement the WebLogic

weblogic.application.ApplicationLifecycleListener interface. A
recommended migration alternative is to use the
javax.servlet.ServletContextListener interface.
Do not use the WebLogic domain for

JMX object names
No
This rule detects a string literal that starts with "com.bea" in Java
code. This string can be used to reference the WebLogic Server
JMX domain and cannot be used as such in WebSphere
Application Server.

MessageProducer API
No
This rule detects the use of the

weblogic.jms.extensions.WLMessageProducer API.

ServletAuthentication invalidateAll
method
No

weblogic.servlet.security.ServletAuthentication invalidateAll
method.

No
TransactionHelper getUserTransaction
method

weblogic.transaction.TransactionHelper getUserTransaction
method.
Do not use UserTransaction interface

from CMT beans
This rule detects references to ctx.lookup(javax.transaction.

UserTransaction) within container managed transaction
enterprise beans. References to the UserTransaction object are
not allowed from CMT beans.
No
These references are flagged so that you can remove this Java EE
violation.
Do not use weblogic.apache packages Yes
This rule detects import and code references to classes where the
class package starts with weblogic.apache and the class maps
directly to an org.apache class.
The quick fix changes the code to org.apache. Download the
appropriate Apache open source .jar file, and include it with
your application.
80
Rule Name
Quick Fix
Action Taken
Do not use WebLogic EJBGEN

annotations
Yes
This rule detects EJBGEN annotations from the weblogic.ejbgen

package. These annotations must be removed from your
application before you deploy it on WebSphere Application
Server.
Do not use WebLogic log4j logging

objects
No
This rule detects the proprietary WebLogic Server log4j classes

and flags them for manual migration.
Do not use WebLogic LoggingHelper

object to get Logger instance
Yes
This rule detects the LoggingHelper object usage.
Do not use WebLogic logging objects
Yes
The quick fix converts the class instance to Java Logger.

This rule detects WebLogic Server logging objects.
The quick fix changes the code to use the Java objects.
Do not use WebLogic

NonCatalogLogger object
Yes
Do not use WebLogic RMI API calls
Yes
This rule detects the NonCatalogLogger usage.

The quick fix converts these objects to Java Logger object. In
addition, it converts all the logging method calls to valid
logging calls. The level is controlled by the user using rule
properties.
This rule detects the use of references to the proprietary
weblogic.rmi packages.
The quick fix changes weblogic.rmi to java.rmi to use the
Java-provided classes.
Do not use WebLogic

RollbackException object
No

weblogic.transaction.RollbackException object and flags it for
manual migration.
Do not use WebLogic servlet

attributes for XML parsing
Yes
This rule detects the use of setAttribute and getAttribute

methods used with specific attributes to parse XML.
The quick fix removes the entries.
Do not use WebLogic

ServletAuthentication class
No
This rule detects the class

weblogic.servlet.security.ServletAuthentication which cannot be
used in WebSphere.
Do not use WebLogic-specific JDBC

properties or extensions
No
This rule detects the use of several WebLogic Server JDBC

properties and extensions that must be manually migrated.
Do not use WebLogic-specific JNDI

environment properties for initial
context
Yes
This rule detects the use of the weblogic.jndi.Environment class

to set context properties.
The quick fix migrates the objects used in the Environment
references to a hash table used to initialize the InitialContext
object.
Appendix E. Third-party application server migration rules and quick fixes
81
Rule Name
Quick Fix
Action Taken
Do not use WebLogic-specific JNDI

property values or the t3 protocol
Yes
This rule detects the use of the following proprietary JNDI name
values:
v java.naming.factory.initial = weblogic.jndi.
WLInitialContextFactory
v java.naming.provider.url = t3://localhost:7001
If found, users are given the option to change the JNDI names
to default portable JNDI name values:
v java.naming.factory.initial = com.ibm.websphere.naming.
WsnInitialContextFactory
v java.naming.provider.url = corbaloc:iiop:localhost:2809
Restriction: The JNDI name values must be in the same Java
source file where the context is initialized with the
javax.naming. InitialContext(Hashtable) constructor.
Do not use WebLogic-specific

packages
No
This rule detects imported classes that begin with weblogic but
not including the weblogic.apache classes. The flagged
server-specific APIs must be migrated.
Do not use WebLogic-specific SSL

protocols
Yes
This rule detects instances of the string literal

"com.certicom.net.ssl" and "weblogic.net" in Java files.
Do not use WebLogic startup or

shutdown classes
Yes
This rule detects classes that implement the WebLogic Server

startup and shutdown interfaces.
The quick fix converts these classes to use the
javax.servlet.ServletContextListener interface and registers it in
the web.xml file of the application.
Do not use WebLogic StAX objects
No
This rule detects the use of WebLogic Server proprietary XML

Streaming (StAX) objects that must be migrated manually.
Do not use WebLogic

TransactionManager object
No
This rule detects the use of the TransactionManager object and

flags it for manual migration.
Do not use WebLogic Transaction

object
No
This rule detects the use of the Transaction object and flags it for
manual migration.
Do not use WebLogic

TransactionSynchronizationRegistry
object
No

TransactionSynchronizationRegistry object and flags it for
manual migration.
Do not use WebLogic WLLevel object Yes
This rule detects WLLevel object usage in a setLevel() method.

The quick fix converts the WLLevel to IBM WsLevel. The level is
controlled by the user using rule properties.
Do not use WebLogic XPath objects
No
This rule detects the use of WebLogic Server proprietary, XML

XPath objects and flags them for manual migration.
Migrate MBeans specific to other

application servers
No
This rule detects all invocations of the

javax.management.ObjectName constructor that might be
application-server specific and would need to be migrated for
the application to run on WebSphere Application Server.
Use compliant UserTransaction

lookup name
Yes
This rule detects references to ctx.lookup("javax.transaction.

UserTransaction").
Within bean managed transaction (BMT) beans, the quick fix
converts the flagged line to ctx.getUserTransaction().
Within servlets, Web applications and client code, the flagged
line is converted to the JNDI lookup: ctx.lookup("java:comp/
UserTransaction")
82
Rule Name
Quick Fix
Action Taken
Use matching throws clause in EJB

bean class
Yes
This rule detects mismatches between the enterprise bean

implementation and the method definitions in the home and
remote interfaces.
The quick fix adds any missing exceptions and removes any
additional exceptions. The interfaces are not changed.
Use OpenJPA property names instead Yes

of Kodo-specific property names
when equivalent
This rule detects the presence of known JPA properties with a

name starting with kodo.* in Java files.
Use OpenJPA property values instead Yes

of Kodo-specific property values
This rule detects the JPA properties with kodo specific values in
Java files.
The quick fix renames these properties to openjpa.*.
The quick fix changes these values to valid openJPA values.

Use portable JNDI names
No
This rule detects the use of the constructor,

javax.naming.InitialContext(Hashtable), specifying not to put
any proprietary WebLogic Server JNDI name values into the
hash table.
Use unitName attribute for Injected

JPA Elements
Yes
This rule detects injected JPA PersistenceContext or

PersistenceUnit elements without unitName or name attributes.
The quick fix adds the missing values to offer similar behavior
to WebLogic Server automated deployment.
WebLogic Server JSP code review rules

The Common JSP code review rules on page 94 are selected with the WebLogic migration rule set. The
WebLogic to WebSphere JSP Migration category has rules specific to WebLogic that are described in the
Rule Name
Quick Fix
Action Taken
Migrate NetUI taglib directives to Yes

Apache Beehive
This rule detects and migrates BEA NetUI taglib directives in JSP
files.
Migrate NetUI tags to Apache

Beehive
Yes
This rule detects and migrates BEA NetUI tags used in JSP files.
Verify use of BEA or Apache

Beehive NetUI tags
No
This rule detects BEA Beehive and Apache Beehive tags so that you
can evaluate the use of this unsupported framework.
WebLogic Server XML file review rules

The XML file review provides a number of rules to detect migration issues with deployment descriptors,
web services, and other XML files.
Rule Name
Quick Fix
Action Taken
Do not use local JNDI names
Yes
This rule detects <local-jndi-name> tags in weblogic-ejb-jar.xml

files.
The quick fix scans all the projects associated with the application
where the local JNDI name is found. If Java code is found that
references the local JNDI name, a <ejb-local-ref> is added to that
project. The Web or EJB bindings are also updated.
83
Rule Name
Quick Fix
Do not use WebLogic servlet filter Yes

for XML parsing
Action Taken
This rule detects the use of an internal WebLogic Server servlet
filter in web.xml files.
The quick fix removes the servlet filter entry along with its filter
mapping entry.
Migrate WebLogic login modules
No
This rule detects <login-config> elements in the WEB-INF/web.xml

file that might indicate that login modules require migration.
Use WebSphere bindings to

define EJB JNDI names
Yes
This rule detects the <jndi-name> tag in weblogic-ejb-jar.xml files

for EJB definitions.
The quick fix migrates the value found to the EJB bindings file.

define EJB local reference JNDI
names
Yes

define EJB reference names
Yes
This rule detects <ejb-local-ref> tags in weblogic-ejb-jar.xml files

for EJB definitions.
This rule detects <ejb-ref-name> in weblogic.xml or
weblogic-ejb-jar.xml files.
The quick fix adds the EJB reference JNDI name to the EJB bindings
file.

Yes
define message-driven bean JNDI
names
This rule detects <destination-jndi-name> for message-driven beans.

define resource environment
reference JNDI names
Yes
This rule detects <resource-env-description> elements in

weblogic.xml or weblogic-ejb-jar.xml files.

define resource reference names
Yes
The quick fix sets the destination JNDI name in the EJB bindings
file.
The quick fix adds the resource reference JNDI name to the EJB
bindings file.
This rule detects <res-ref-name> elements in weblogic.xml or
The quick fix adds the resource reference JNDI name to the EJB
bindings file.
Use WebSphere extensions to

define transaction timeout
seconds
Yes
This rule detect the <trans-timeout-seconds> in

The quick fix defines the timeout value to the EJB extensions file.

Yes
define virtual directory mappings
This rule detects WebLogic Server virtual directory mapping

configuration and migrates entries to use WebSphere file serving.

define web module context root
Yes
This rule detects the <context-root> element in weblogic.xml files.
Detect Oracle auto-generated

keys
No
The quick fix defines the context root value to the Web extensions
file.
This full profile rule detects Oracle auto-generated keys defined in
the weblogic-cmp-rdbms-jar.xml file. These keys are used for
container managed persistence entity beans. The application must
be modified to support keys generation.
Do not use WebLogic-specific EJB No

Query Language constructs
This full profile rule detects query language elements, weblogic-ql,

in weblogic-cmp-rdbms-jar.xml files for manual migration.

JNDI name values or the t3
protocol
This full profile rule detects non-portable WebLogic Server JNDI

lookup values or URLs with the t3 or t3s protocol.
84
Yes
Rule Name
Quick Fix
Action Taken
Do not use WebLogic web

services deployment descriptor
Yes
This full profile rule flags webservices.xml J2EE deployment

descriptor files.
The quick fix generates an Ant script that uses IBM WebSphere Ant
tasks, which generate the appropriate artifacts for the list of web
services, based on the information collected from the deployment
descriptors. Depending on the deployment descriptor, the fix might
also generate the Service Endpoint Interface (SEI) for the service,
and add it to the project class path. You can then run the Ant script,
copy the generated artifacts to the project, and possibly add
additional targets such as the endpoint enabler, for example.

define CMP mappings
Yes
This full profile rule detects <weblogic-rdbms-jar> elements in

weblogic-cmp-rdbms-jar.xml files.
The quick fix uses the weblogic-cmp-rdbms-jar.xml file to generate
the EJB to RDB mapping files used by WebSphere Application
Server for CMP.

define concurrency strategy
Yes
This rule detects the <concurrency-strategy> element in

The quick fix moves the Exclusive, ReadOnly, Database, and
Optimistic options to the EJB extensions file.
The following rules handle WebLogic Server JPA persistence XML migration:
Rule Name
Quick Fix
Action Taken
Do not use kodo

PersistenceServerServlet in
web.xml
Yes
This rule detects the presence of servlet,

kodo.remote.PersistenceServerServlet, in web.xml files.
Do not use kodo properties that

have no openJPA equivalent
Yes
The quick fix removes the servlet along with its servlet mapping
elements.
This rule detects the use of kodo.* properties that do not have
openjpa equivalent.
The quick fix deletes the kodo property from persistence.xml files.
Use OpenJPA property names

instead of Kodo-specific property
names when equivalent
Yes
Use OpenJPA property values

instead of Kodo-specific property
values
Yes
This rule detects the presence of known JPA properties with a name
starting with kodo.* in persistence.xml files.
The quick fix renames these properties to openjpa.*.
This rule detects the JPA properties with kodo-specific values in
persistence.xml files.
The quick fix changes these values to valid OpenJPA values.
The following rules flag any WebLogic Server unhandled or partially handled XML file:
Rule Name
Quick Fix
Action Taken
Do not use weblogic.xml file
No
This rule flags the weblogic.xml file so that you can look for any
unmigrated elements at the end of the application migration.
Do not use weblogicapplication.xml file
No
This rule flags the weblogic-application.xml file so that you can

look for any unmigrated elements at the end of the application
migration.
85
Rule Name
Quick Fix
Action Taken
Do not use weblogic-cmp-jar.xml

file
No
This rule flags the weblogic-cmp-jar.xml file so that you can look
for any unmigrated elements at the end of the application
migration.
Do not use weblogic-cmp-rdbmsjar.xml file
No
This rule flags the weblogic-cmp-rdbms-jar.xml file so that you can

migration.
Do not use weblogicdiagnostics.xml file
No
This rule flags the weblogic-diagnostics.xml file so that you can

migration.
Do not use weblogic-ejb-jar.xml

file
No
This rule flags the weblogic-ejb-jar.xml file so that you can look
migration.
Do not use weblogic-ra.xml file
No
This rule flags the weblogic-ra.xml file so that you can look for any
WebLogic Server file review rules

Under the BEA Beehive to Apache Beehive category, the WebLogic Server rule set has rules to identify
BEA Beehive control files.
Rule Name
Quick Fix
Action Taken
Do not use BEA Global.app files
No
This rule detects BEA Beehive Global.app application control files.
Do not use BEA Java Web

Services (JWS) files
No
This rule detects BEA Beehive JWS files.
Do not use Java Control

Extension (JCX) files
No
This rule detects BEA Beehive JCX files.
Do not use Java Page Flow (JPF)

files
No
This rule detects BEA Beehive JPF files.
Under the MANIFEST.MF Review category, the WebLogic Server rule set has a rule to verify that the
MANIFEST.MF class path is set up correctly.
Rule Name
Quick Fix
Action Taken
Use MANIFEST.MF for

application class path
Yes
This rule detects any classes or libraries contained within an

APP-INF directory of an EAR file.
The quick fix adds an entry to the class path of each affected web
module by updating the class path entry of the MANIFEST.MF file of
the module.
Under the Properties File Review category, the WebLogic Server rule set has a rule to analyze properties
files.
Rule Name
Quick Fix
Action Taken

JNDI name values or the t3
protocol
No
This rule detects non-portable WebLogic Server JNDI lookup values

or URLs with the t3 or t3s protocol in properties files.
86
JBoss Application Server rules and quick fixes

The JBoss to WebSphere Application Migration Tool feature evaluates Java code, JSP code, deployment
descriptors, and web services deployment descriptors from JBoss Application Server applications as part
of its analysis set. The following rules and quick fixes are available to help migrate JBoss Application
Server applications.
When you select the JBoss Application Migration rule set, relevant JBoss Application Server rules,
framework rules, and Java SE rules will be selected. The JBoss Application Server specific rules are
described in this section. The Java SE rules are described in Appendix D, Java SE version migration, on
page 71. The Java SE rules selected depend on your source and target Java Runtime Environment
configuration when you choose the rule set. The framework rules are described in Framework
migration on page 95.
JBoss Java code review rules

Under the Java code review set of rules, the JBoss to WebSphere code migration category contains
Rule Name
Quick Fix
Action Taken
Do not start threads within the

web or EJB containers
No
This rule detects code that creates threads in web or EJB modules.
Do not use JBoss-specific naming

lookup strings
No
This rule detects the use of JBoss Application Server naming lookup
strings that start with "java:", such as "java:jboss" and "java:jdbc".
Strings that start with "java:" or "java:/" are also detected because
the content afterwards might contain JBoss Application Server
values.
Do not use JBoss-specific

packages
No
This rule detects imported classes that begin with org.jboss. These
classes must be manually migrated.
Do not use JBoss-specific send or

receive timeout constants
No
This rule detects JBoss Application Server connection and response

timeout constants such as org.jboss.ws.timeout.
Do not use JBoss-specific string

literals
No
This rule detects general JBoss Application Server strings that are
not covered by other rules.
Do not use MBeans for JBoss

application startup or shutdown
logic
Yes
This rule detects classes that implement the MBean registration

interface to run application startup and shutdown logic.

application servers
No

application-server specific and would need to be migrated for the
application to run on WebSphere Application Server.
Use portable JNDI property

values
No
This rule detects the use of the constructor,

javax.naming.InitialContext(Hashtable), specifying not to put any
proprietary JBoss Application Server JNDI name values into the
hash table.
The quick fix that is provided for this rule converts the class to
implement the ServletContextListener interface to perform startup
and shutdown logic.
Important: If your code provides MBeans and it implements
MBeanRegistration for its intended purpose, you should turn off
this rule.
87
Rule Name
Quick Fix
Action Taken
Do not use JBoss-specific JNDI

property values
Yes
This full profile rule detects the use of these JNDI property values:
v java.naming.factory.initial = org.jnp.interfaces.
NamingContextFactory
v java.naming.provider.url = jnp://localhost:1099
If these values are found, an option is provided to change the JNDI
names to default portable JNDI name values:
v java.naming.factory.initial = com.ibm.websphere.naming.
WsnInitialContextFactory
v java.naming.provider.url= corbaloc:iiop:localhost:2809
Restriction: The JNDI name values must be in the same Java
source file where the context is initialized with the javax.naming.
InitialContext(Hashtable) constructor.
Do not use JBoss-specific send or

receive timeout constants
No
This full profile rule detects JBoss JAX-RPC and JAX-WS timeout
constants to be migrated to IBM web service timeout constants.
JBoss Application Server JSP code review rules

The Common JSP code review rules on page 94 are selected with the JBoss migration rule set.
JBoss Application Server XML file review rules

Rule Name
Quick Fix
Action Taken
Do not use local JNDI names
Yes
This rule detects <local-jndi-name> tags in jboss.xml files.

The quick fix scans all the projects associated with the application
where the local JNDI name is found. If Java code is found that
references the local JNDI name, an <ejb-local-ref> is added to that
project. The Web or EJB bindings are also updated.
Manually migrate resource

references for URLs and resource
managers
No
This rule detects <res-ref-name> elements in jboss-web.xml or

jboss.xml files that define URL resources or resource manager
resources. These resource references must be manually migrated.
Migrate JBoss login modules
No
This rule detects <security-domain> elements in the jboss-web.xml

file and <login-config> elements in the WEB-INF/web.xml file that
might indicate that login modules require migration.

define EJB JNDI names
Yes
This rule detects the <jndi-name> tag in jboss.xml files for EJB
definitions.

define EJB local reference JNDI
names
Yes

Yes
This rule detects <ejb-local-ref> tags in jboss.xml files for EJB

definitions.
This rule detects <ejb-ref-name> in jboss-web.xml or jboss.xml
files.
The quick fix adds the JNDI name of the EJB reference to the EJB
bindings file.
88
Rule Name
Quick Fix
Action Taken

Yes
define message-driven Bean JNDI
names

define resource environment
reference JNDI names
Yes
This rule detects the JBoss Application Server resource environment

reference JNDI names in the jboss-web.xml or jboss.xml files. The
quick fix migrates the JNDI name to the bindings file.

Yes
This rule detects <res-ref-name> elements in jboss-web.xml or

jboss.xml files.
file.
The quick fix adds JNDI name of the resource reference to the EJB
bindings file.
define web module context root
Yes
Do not use JBoss web services

deployment descriptor
Yes
This rule detects the <context-root> element in jboss-web.xml files.

The quick fix defines the context root value in the Web extensions
file.
This full profile rule flags webservices.xml J2EE deployment
descriptor files.
services based on the information collected from the deployment
also generate the Service Endpoint Interface (SEI) for the service
additional targets such as the endpoint enabler.

define CMP mappings
Yes
This full profile rule detects <jbosscmp-jdbc> elements in

jbosscmp-jdbc.xml files.
The quick fix uses the jbosscmp-jdbc.xml file to generate the EJB to
RDB mapping files used by WebSphere Application Server for CMP.
The following rule flags any JBoss Application Server unhandled or partially handled XML file:
Rule Name
Quick Fix
Action Taken
Do not use jboss.xml file
No
This rule flags the jboss.xml file so that you can look for any
Do not use jboss-app.xml file
No
This rule flags the jboss-app file so that you can look for any
Do not use jboss-client.xml file
No
This rule flags the jboss-client.xml file so that you can look for
any unmigrated elements at the end of the application migration.
Do not use jbosscmp-jdbc.xml file No
This rule flags the jbosscmp-jdbc.xml file so that you can look for
Do not use jboss-web.xml file
This rule flags the jboss-web.xml file so that you can look for any
No
JBoss Application Server file review rules

Under the MANIFEST.MF Review category, the JBoss rule set has a rule to verify that the MANIFEST.MF
class path is set up correctly.
89
Rule Name
Quick Fix
Action Taken
Use MANIFEST.MF for

application class path
Yes
This rule detects JAR files and classes in the EAR project root
folder.
The quick fix adds the JAR files and the classes to the
MANIFEST.MF file so that they are detected by WebSphere
Application Server.
Under the Properties File Review category, the JBoss rule set has a rule to analyze properties files.
Rule Name
Quick Fix
Action Taken
Do not use JBoss-specific JNDI

property values
No
This rule detects JBoss-specific JNDI property values.
Oracle Application Server rules and quick fixes

The Oracle to WebSphere Application Migration Tool feature evaluates Java code, JSP code, deployment
descriptors, and web services deployment descriptors from Oracle Application Server applications as part
of its analysis set. The following rules and quick fixes are available to help migrate Oracle Application
Server applications.
When you select the Oracle Application Migration rule set, relevant Oracle Application Server rules,
framework rules, and Java SE rules will be selected. The Oracle Application Server specific rules are
described in this section. The Java SE rules are described in Appendix D, Java SE version migration, on
page 71. The Java SE rules selected depend on your source and target Java Runtime Environment
configuration when you choose the rule set. The framework rules are described in Framework
migration on page 95.
Oracle Application Server Java code review rules

Under the Java code review set of rules, the Oracle to WebSphere code migration category contains
Rule Name
Quick Fix
Action Taken
Do not cast java.sql.Connection as No

OracleConnection directly
This rule detects specific instances of the class OracleConnection

where the class is used to cast a java.sql.Connection object and a
class cast exception might result.

No
Do not use Oracle-specific APIs
No
This rule flags imported classes within Oracle Application Server

packages that must be manually migrated.
Do not use Oracle-specific

InitialContext properties
No
This rule detects Oracle Application Server properties within the

initialization of an InitialContext using the constructor,
javax.naming.InitialContext(Hashtable).
Do not use Oracle startup and

shutdown interfaces
No
This rule detects the use of the oracle.j2ee.server.OC4JShutdown

and oracle.j2ee.server.OC4JStartup interfaces used to execute code
during application startup or shutdown.

application servers
No

90
Oracle Application Server JSP code review rules

The Common JSP code review rules on page 94 are selected with the Oracle migration rule set. The
Oracle to WebSphere JSP Migration category has rules specific to Oracle that are described in the
Rule Name
Quick Fix
Do not use proprietary Oracle tag No

libraries
Action Taken
This rule looks for proprietary Oracle Application Server tag
libraries in JSP files.
Oracle Application Server XML file review rules

Rule Name
Quick Fix
Action Taken
Do not use custom Oracle

Application Shared Libraries
No
This rule detects the tag <imported-shared-libraries> in the

orion-application.xml file.
Do not use Oracle global

load-on-startup servlet
No
This rule detects servlets that are marked with the

<load-on-startup> tag in the global-web-application.xml file.
Do not use Oracle servlet invoker No
This rule detects an Oracle Application Server servlet invoker using

the <servlet-webdir> tag in the orion-web.xml or
global-web-application.xml file.
Do not use Oracle-specific web

filters
This rule detects the use of web filters that start with "oracle."
defined in the web.xml.
Yes
The quick fix deletes the filter element.

Do not use Oracle-specific web
listeners
Yes
This rule detects the use of web listeners that start with "oracle."
defined in the web.xml.
The quick fix deletes the listener element.
Migrate Oracle login modules
No
This rule detects login modules that are marked with the
<login-modules> tag in the orion-application.xml file.

Yes
This rule detects EJB references in the orion-web.xml or

orion-ejb-jar.xml files.
The quick fix adds the JNDI name of the EJB reference to the EJB
bindings file.

Yes
define message-driven bean JNDI
names

This rule detects resource references in the orion-web.xml or

orion-ejb-jar.xm files.
Yes
file.
The quick fix adds the JNDI name of the resource reference to the
EJB bindings file.
Use WebSphere configuration to
control class loader order
No
Do not use MDB 2.0 listener ports No
This rule detects the presence of the search-local-classes-first setting

used to control class loading order.
This full profile rule detects the message-driven bean (MDB) 2.0
listener ports in the ejb-jar.xml file.
91
Rule Name
Quick Fix
Action Taken
Do not use Oracle web services

deployment descriptor
Yes
This full profile rule flags oracle-webservices.xml J2EE

deployment descriptor files.
services, based on the information collected from the deployment
also generate the Service Endpoint Interface (SEI) for the service,
additional targets such as the endpoint enabler, for example.

define CMP mappings
No
This full profile rule detects enterprise bean to relational database

mappings that are used for container-managed persistence (CMP).

define concurrency strategy
Yes
This full profile rule detects and migrates the concurrency strategy
used for EJB persistence.
The quick fix locates the concurrency strategy settings in the
orion-ejb-jar.xml file and sets equivalent properties in the
WebSphere extension file.
The following rules flag any Oracle Application Server unhandled or partially handled XML file:
Rule Name
Quick Fix
Action Taken
Do not use data-sources.xml file
No
This rule flags the data-sources.xml file so that you can look for
Do not use global-webapplication.xml file
No
This rule flags the global-web-application.xml file so that you can

migration.
Do not use jazn-data.xml file
No
This rule flags the jazn-data.xml file so that you can look for any
Do not use oc4j-connectors.xml

file
No
This rule flags the oc4j-connectors.xml file so that you can look for
Do not use oc4j-ra.xml file
No
This rule flags the oc4j-ra.xml file so that you can look for any
Do not use oraclewebservices.xml file
No
This rule flags the oracle-webservices.xml file so that you can look
migration.
Do not use orion-application.xml

file
No
This rule flags the orion-application.xml file so that you can look
migration.
Do not use orion-applicationclient.xml file
No
This rule flags the orion-application-client.xml file so that you

can look for any unmigrated elements at the end of the application
migration.
Do not use orion-ejb-jar.xml file
No
This rule flags the orion-ejb-jar.xml file so that you can look for
Do not use orion-web.xml file
No
This rule flags the orion-web.xml file so that you can look for any
92
Oracle Application Server file review rules

Under the Properties File Review category, the Oracle rule set has a rule to analyze properties files.
Rule Name
Quick Fix
Action Taken
Do not use Oracle-specific

InitialContext properties
No
This rule detects Oracle-specific JNDI property values.
Apache Tomcat rules and quick fixes

The Apache Tomcat to WebSphere Application Migration Tool for feature evaluates Java code, JSP code,
and deployment descriptors and XML files from Apache Tomcat applications as part of its analysis set.
The following rules and quick fixes are available to help migrate Apache Tomcat applications.
When you select the Tomcat Application Migration rule set, relevant Tomcat rules, framework rules, and
Java SE rules will be selected. The Tomcat specific rules are described in this section. The Java SE rules
are described in Appendix D, Java SE version migration, on page 71. The Java SE rules selected depend
on your source and target Java Runtime Environment configuration when you choose the rule set. The
framework rules are described in Framework migration on page 95.
Apache Tomcat Java code review rules

Under the Java code review set of rules, the Apache Tomcat to WebSphere code migration category
contains multiple rules. For more information, press F1 when viewing the rule in the Software Analyzer
Rule Name
Quick Fix
Action Taken
Avoid using the invalid initial

context java:/comp
Yes
This rule detects an invalid initial context string that starts with
java:/comp instead of java:comp (without the "/").

No
Do not use Tomcat

org.apache.juli.logging
Yes
This rule detects logging methods from the

org.apache.juli.logging package and will help migrate your
application to use the java.util.logging.Logger class.
Do not use Apache Tomcat

packages and APIs
No
This rule detects instances of Apache Tomcat specific packages and

APIs which need to be migrated.
Do not use the Apache Tomcat

BasicDataSource
No
This rule detects instances of the

org.apache.tomcat.dbcp.BasicDataSource class that is not available
in WebSphere.
Do not use the

org.apache.tomcat.websocket.
server.WsServerContainer
doUpgrade method
No
Migrate the Tomcat WsServerContainer doUpgrade method to the

new IBM WebSocket API WsWsocServerContainer doUpgrade
method.
Ensure context lookups have

corresponding deployment
descriptor entries
No
This rule detects initial context lookups so that you can check for
corresponding environment variable entries in the web.xml file.

application servers
No

Apache Tomcat JSP file code review rules

The Common JSP code review rules on page 94 are selected with the Tomcat migration rule set.
93
Apache Tomcat XML code review rules

When using Apache Tomcat, Java EE deployment descriptor configuration is not required within the
application and is often provided within the Context definition. The Context can be configured within the
application, in the server.xml file, or within the server configuration directory. When the configuration is
provided within the application in the META-INF/context.xml file, it is migrated to the corresponding
web.xml file or WebSphere bindings and extensions files. If the Context configuration is not contained
within an application, the information must be migrated manually.
Rule Name
Quick Fix
Action Taken
Avoid using a / in a web module Yes

welcome file name
This rule flags any web module <welcome-file> that starts with a
slash character (/) or a backslash character (\) in the web.xml file.
Avoid using the invalid initial

context java:/comp
Yes
This rule detects an invalid initial context string that starts with
java:/comp instead of java:comp within XML files.
Do not use context valve

component
No
This rule flags all Context <Valve> elements in the

META-INF/context.xml file. Use Java servlet filters instead.
Set the sharing scope on resource

references
Yes
This rule flags any resource references that do not have the resource
sharing scope set. The resource sharing scope defaults to Shareable
on Tomcat. Set the sharing scope the same on WebSphere.
Use Java EE deployment

descriptors and WebSphere
bindings to define resource link
references
Yes
This rule migrates the ResourceLink Context element from the

META-INF/context.xml file to the web.xml file and WebSphere
bindings.

descriptors and WebSphere
bindings to define resource
references
Yes
This rule migrates the Resource Context element from the

META-INF/Context.xml file to the web.xml file and WebSphere
bindings.

descriptors to define context
lifecycle listeners
No
This rule migrates the Context Lifecycle Listener information from

the META-INF/Context.xml file to the web.xml file.

descriptors to define context
parameters
Yes
This rule migrates the Context parameter information from the

META-INF/Context.xml file to the web.xml file.

Yes
descriptors to define environment
references
This rule migrates Context Environment information from the

META-INF/context.xml file to the web.xml file.

descriptors to define missing
security roles
This rule flags <auth-constraint> elements in web.xml that are

missing associated security-role elements.
Yes
Common JSP code review rules

These JSP rules are available to competitive migration rule sets. For more information, press F1 when
viewing the rule in the results viewer.
Rule Name
Quick Fix
Action Taken
Avoid nesting single or double

quotes in JSP tags
Yes
This rule detects JSP tags where single quotes are nested within
single quotes or where double quotes are nested within double
quotes.
94
Rule Name
Quick Fix
Action Taken
Avoid using a .jsp extension for

JSP fragments
Yes
This rule detects JSP fragments included in another JSP file. If the
JSP fragment file has a .jsp extension rather than a .jspf extension,
the file is flagged.
The quick fix takes you to the refactor options to change the file
name and all of its references.
Check for valid configuration of

No
the getQueryString method in JSP
welcome files
This rule detects request.getQueryString() method calls in JSP

welcome files of a web module. These calls are flagged so that you
can verify that the method is called correctly and avoid null values
for the query string.
Do not redefine a taglib prefix

using a different URI
No
This rule detects JSP taglib directives that associate the same prefix
attribute value with different uri attribute values.
Do not use Java keywords in JSP

and JSF expression language
elements
No
This rule detects JSP expression language (EL) elements with

variables names that contain Java keywords or EL reserved
keywords.
Use correct case for tag attribute

names
Yes
This rule validates that JSP tag attributes match the case as defined
in the tag library definition (TLD) file if it is available.
TLD file review rules

This rule contains rules that validate custom tag library definition files.
Rule Name
Quick Fix
Action Taken
Check custom tag library

definition attribute names
No
This rule validates custom tag library definition (TLD) file tag
attribute names with the getter and setter methods in the tag class.
Framework migration
Under the Java Code Review and the XML File Review categories of rules, the Framework migration
category contains rules for recognizing some of the commonly used frameworks that might need changes
to work on WebSphere Application Server. The framework rules described in this section are
automatically selected with the competitive tool rule sets.
The following Java or XML framework detection rules trigger only once per project to let you know the
framework was detected. The rules provide information to help you verify that the framework is
compatible with WebSphere Application Server.
Table 29. Framework migration

Rule Name
Check for the Hibernate framework
No
This rule scans Java artifacts to detect the use of the

Hibernate framework.
Check the Hibernate configuration
No
This rule scans hibernate.cfg.xml files to detect Hibernate

properties that are not configured to work with WebSphere
Application Server.
Check the Hibernate mapping files
No
This rule detects Hibernate mapping files. To migrate from

Hibernate to WebSphere JPA, use the Hibernate to WebSphere
JPA rule set."
Check for the Seam framework
No
This rule scans Java and XML artifacts to detect the use of the
Seam framework.
95
Table 29. Framework migration (continued)

Rule Name
Check for the Spring framework
No
This rule scans Java and XML artifacts to detect the use of the
Spring framework.
Detect usage of the Quartz scheduler
No
This rule flags the presence of the Quartz Job Scheduler by

detecting the use of any classes under the org.quartz package.
Using this scheduler is discouraged because it creates
unmanaged threads, which results in limited access to
container resources.
Framework XML - Spring best practices rules

The framework XML rules check certain Spring artifacts to help you make sure that you are using Spring
in a manner compatible with WebSphere Application Server. Quick fixes are available to fix some of the
configuration issues. The quick fixes do not migrate Spring-based applications to other Java EE
technologies.
Rule Name
Check for valid configuration for

DefaultMessageListenerContainer
No
This rule flags the Spring beans that use

DefaultMessageListenerContainer so the user can check for
valid configuration for WebSphere.
Check for valid configuration for

Yes
LocalContainerEntityManagerFactoryBean
This rule flags the Spring beans that use the class
LocalContainerEntityManagerFactoryBean so the user can
check for valid configuration for WebSphere.
Check for valid JNDI environment

values
No
This rule flags the environment element in a jndi-lookup

element and the property named jndiEnvironment to let the
user verify that the values used are valid.
Check Spring jndi-lookup element

configuration
No
This rule flags the element jndi-lookup to let the user verify
that the usage is valid.
Check Spring JndiObjectFactoryBeans

configuration
No
This rule flags the Spring beans with the class

JndiObjectFactoryBean to let the user verify that the values
used are valid.
Check the entityInterceptor property in

the Spring configuration
No
This rule flags the use of the entityInterceptor property

defined on transaction managers that are commonly migrated
when moving to WebSphere Application Server. The
entityInterceptor property is not supported on all transaction
managers.
Check the Spring configuration defined

by the contextConfigLocation
context-param element
No
This rule checks for the existence of Spring configuration files

not flagged by other rules.
Detect invalid Spring jndi-lookup

element configuration
Yes
This rule flags the element jndi-lookup in web projects to let

the user correct the configuration.
Detect invalid Spring

JndiObjectFactoryBean configuration
Yes
This rule flags the Spring jndiName property in web projects

to let the user verify that the usage is valid.
Do not use different styles to create

EntityManagerFactory
No
This rule flags the Spring beans that create the

EnityManagerFactory in two styles using
LocalEntityManagerFactoryBean and
LocalContainerEntityManagerFactoryBean in the same Spring
configuration file.
Do not use NativeJdbcExtractor
No
This rule flags the property named nativeJdbcExtractor. The

user should use WSCallHelper instead.
96
Rule Name
Do not use unsupported JTA Transaction Yes

Manager
This rule flags the Spring beans that use

WebSphereTransactionManagerFactoryBean or
WebLogicJtaTransactionManager or JtaTransactionManager for
transaction management. The user should use
WebSphereUowTransactionManager instead.
Hibernate to WebSphere JPA migration

The Hibernate to WebSphere JPA rule set provides Java and XML rules that migrate Hibernate
application interfaces and methods and Hibernate configuration XML to WebSphere JPA equivalents.
These rules are made available as a separate rule set and are not automatically selected with the
competitive tool rule sets.
Hibernate to WebSphere JPA - Java rules

The Hibernate to WebSphere JPA Java rules are located under the Java Code Review > Framework
migration category of rules. These rules provide information on how to migrate commonly used
Hibernate interfaces and methods. You must manually migrate your Hibernate code to WebSphere JPA.
For migration guidance, use the information and samples in the detailed help for each rule.
Table 30. Framework migration

Rule Name
Do not use Hibernate packages
No
This rule detects the use of Hibernate package references that

are not covered by other rules.
Do not use the Hibernate Configuration

buildSessionFactory method
No
This rule flags the org.hibernate.cfg.Configuration

buildSessionFactory method. Use the
javax.persistence.Persistence createEntityManagerFactory
method instead.
Do not use the Hibernate Query

getNamedParameters method
No
This rule flags the org.hibernate.Query getNamedParameters

method. Use the javax.persistence.Query getParameters
method instead.
Do not use the Hibernate Query list

method
No
This rule flags the org.hibernate.Query list method. Use the

javax.persistence.Query getResultList method instead.

methods to set parameters
No
This rule flags org.hibernate.Query set-parameter methods.

Use the javax.persistence.Query setParameter method instead.

setParameterList or setParameters
methods
No
This rule flags the org.hibernate.Query setParameterList and

setParameters methods. Use the javax.persistence.Query
setParameter method instead.

uniqueResult method
No
This rule flags the org.hibernate.Query uniqueResult method.

Use the javax.persistence.Query getSingleResult method
instead.
Do not use the Hibernate Session

beginTransaction method
No
This rule flags the org.hibernate.Session beginTransaction

method. Use the javax.persistence.EntityManager
getTransaction method followed by a call to
javax.persistence.EntityTransaction begin method instead.

createCriteria method
No
This rule flags the org.hibernate.Session createCriteria

getCriteriaBuilder method followed by a call to the
javax.persistence.criteria.CriteriaBuilder createQuery method.
97
Table 30. Framework migration (continued)

Rule Name

createQuery method
No
This rule flags the org.hibernate.Session createQuery method.

Use the javax.persistence.EntityManager createQuery method
instead.

createSQLQuery method
No
This rule flags the org.hibernate.Session createSQLQuery

createNativeQuery method instead.
Do not use the Hibernate Session delete

method
No
This rule flags the org.hibernate.Session delete method. Use

the javax.persistence.EntityManager remove method instead.
Do not use the Hibernate SessionFactory

interface
No
This rule flags uses of the org.hibernate.SessionFactory

interface. Use the javax.persistence.EntityManagerFactory
interface instead.

isClosed method
No
This rule flags the org.hibernate.SessionFactory isClosed

method. Use the javax.persistence.EntityManagerFactory
isOpen method instead.

openSession method
No
This rule flags the org.hibernate.SessionFactory openSession

method. Use the javax.persistence.EntityManagerFactory
createEntityManger method instead.

getNamedQuery method
No
This rule flags the org.hibernate.Session getNamedQuery

createNamedQuery method instead.

getSessionFactory method
No
This rule flags the org.hibernate.Session getSessionFactory

getEntityManagerFactory method instead.

interface
No
This rule flags the org.hibernate.Session interface. Use the

javax.persistence.EntityManager interface instead.
Do not use the Hibernate Session load

method
No
This rule flags the org.hibernate.Session load method. Use the

javax.persistence.EntityManager find method instead.
Do not use the Hibernate Session save

method
No
This rule flags the org.hibernate.Session save method. Use the

javax.persistence.EntityManager persist method instead.

saveOrUpdate method
No
This rule flags the org.hibernate.Session saveOrUpdate

method. Use the javax.persistence.EntityManager merge
method instead.
Do not use the Hibernate Session update No

method
This rule flags the org.hibernate.Session update method. Use

the javax.persistence.EntityManager merge method instead.
Do not use the Hibernate Transaction

interface
No
This rule flags uses of the org.hibernate.Transaction interface,

org.hibernate.JDBCTransaction class, and
org.hibernate.JTATransaction class. Replace the use of the
Transaction interface and the JDBCTransaction class with the
javax.persistence.EntityTransaction interface. Replace the use
of the JTATransaction class with the
javax.transaction.UserTransaction interface.
Migrate HQL FROM clause used as a

query
Yes
This rule detects and migrates Hibernate Query Language

(HQL) strings that begin with a FROM clause. In JPA, query
strings must begin with a SELECT clause.
Migrate HQL ORDER BY

UPPER/LOWER clauses
No
This rule detects Hibernate Query Language (HQL) strings

that contain ORDER BY UPPER or ORDER BY LOWER clauses that
must be migrated for use with JPA.
98
Hibernate to WebSphere JPA - XML rules

The Hibernate to WebSphere JPA XML rules are located under the XML File Review > Framework
migration category of rules. These rules provide information on how to migrate Hibernate configuration
and mapping files to their WebSphere JPA equivalents.
Rule Name
Migrate Hibernate hbm.xml to JPA

orm.xml
Yes
This rule helps to migrate Hibernate mapping (HBM) files to

JPA object-relational mapping (ORM) files. This rule flags all
XML files that have a hibernate-mapping root element.
The quick fix for this rule creates a new ORM XML file
named <name>orm.xml in the same folder as the
corresponding <name>hbm.xml file.
Migrate Hibernate hibernate.cfg.xml to

JPA persistence.xml
Yes
This rule flags Hibernate configuration files

(hibernate.cfg.xml) for migration to JPA configuration files
(persistence.xml).
The quick fix for this rule creates a persistence.xml file in
the same folder as the corresponding Hibernate configuration
file.
99
100
Appendix F. Migrated Apache Tomcat configuration elements

In Apache Tomcat, certain configuration required by an application can be in the server.xml,
context.xml, or web.xml files, which are located in the Tomcat conf directory. The server.xml and
context.xml files can also reference the default tomcat-users.xml file located in the Tomcat conf directory
or user-defined configuration files that contain tomcat-users elements. Additional configuration can be in
the META-INF/context.xml or WEB-INF/web.xml files of the application.
Configuration elements that the tool does not migrate must be migrated manually to the Liberty profile
server configuration.
Configuration elements that are migrated from the conf/server.xml file

The tool migrates elements from the Tomcat conf/server.xml file to the Liberty profile
migratedConfig/server.xml file.
Table 31. Configuration elements that are migrated from the conf/server.xml file
Tomcat configuration element
Liberty profile configuration

element
Migrated attributes
Tomcat attribute = Liberty profile
attribute
Service/Connector with scheme attribute http

and protocol attributes: default, 'HTTP/1.1',
'org.apache.coyote.http11.Http11NioProtocol',
'org.apache.coyote.http11.Http11Protocol'
httpEndpoint
port = httpPort
redirectPort = httpsPort
Server/Service/Engine/
@defaultHost = host
connectionTimeout =
httpOptions/@persistTimeout
maxThreads =
httpOptions/
@maxKeepAliveRequests
socket.soReuseAddress =
tcpOptions/@soReuseAddr
101
Table 31. Configuration elements that are migrated from the conf/server.xml file (continued)

element
Migrated attributes
attribute
Service/Connector with scheme attribute https

and protocol attribute default or 'HTTP/1.1' or
'org.apache.coyote.http11.Http11NioProtocol' or
'org.apache.coyote.http11.Http11Protocol'
httpEndpoint
port = httpsPort
Server/Service/Engine/
@defaultHost = host
connectionTimeout =
httpOptions/@persistTimeout
maxThreads =
httpOptions/
@maxKeepAliveRequests
socket.soReuseAddress =
tcpOptions/@soReuseAddr
sslProtocol = ssl/@sslProtocol
clientAuth (true) =
ssl/@clientAuthentication
clientAuth (want) =
ssl/
@clientAuthenticationSupported
ciphers = ssl/@enabledCiphers
keystoreFile =
keystore/@location
keystoreType = keystore/@type
keystorePass =
keystore/@password (xor
encoded using the
securityUtility command)
truststoreFile =
keystore/@location
truststoreType =
keystore/@type
truststorePass =
keystore/@password (xor
encoded using the
Service/Engine/Host
virtualHost
name = id
Alias = hostAlias
102

element
Migrated attributes
attribute
Resource with driverClassName

'org.apache.derby.jdbc.EmbeddedDriver'
dataSource
name = jndiName
username =
containerAuthData/@user
password =
containerAuthData/@password
(xor encoded using the
url =
properties.derby.embedded/
@createDatabase,
@databaseName
defaultTransactionIsolation =
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
maxIdle = connectionManager/
@minPoolSize
maxWait = connectionManager/
@connectionTimeout

'com.ibm.db2.jcc.DB2Driver'
dataSource
name = jndiName
username =
password =
url = properties.db2.jcc/
@databaseName, @serverName,
@portNumber
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
@minPoolSize
@connectionTimeout
103

element
Migrated attributes
attribute

'oracle.jdbc.driver.OracleDriver' or
'oracle.jdbc.OracleDriver'
dataSource
name = jndiName
username =
password =
url = properties.oracle/@URL,
@driverType
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
@minPoolSize
@connectionTimeout

'com.sybase.jdbc3.jdbc.SybDriver' or
'com.sybase.jdbc4.jdbc.SybDriver'
dataSource
name = jndiName
username =
password =
url = properties.sybase/
@databaseName, @serverName,
@portNumber
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
@minPoolSize
@connectionTimeout
104

element
Migrated attributes
attribute

'com.ddtek.jdbc.sqlserver.SQLServerDriver'
dataSource
name = jndiName
username =
password =
url =
properties.datadirect.sqlserver/
@serverName, @portNumber,
@databaseName
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
@minPoolSize
@connectionTimeout

'com.microsoft.sqlserver.jdbc.SQLServerDriver'
dataSource
name = jndiName
username =
password =
url =
properties.microsoft.sqlserver/
@URL
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
@minPoolSize
@connectionTimeout
105

element
Migrated attributes
attribute

'com.ddtek.jdbc.sqlserver.SQLServerDriver'
dataSource
name = jndiName
username =
password =
url =
properties.datadirect.sqlserver/
@serverName, @portNumber,
@databaseName
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
@minPoolSize
@connectionTimeout

'com.mysql.jdbc.Driver'
dataSource
name = jndiName
username =
password =
url = properties/@URL
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
@minPoolSize
@connectionTimeout
Resource with type

jmsConnectionFactory
'org.apache.activemq.ActiveMQConnectionFactory'
name = jndiName
Resource with type

'org.apache.activemq.command.ActiveMQTopic'
name = jndiName
jmsTopic
id = jndiName
physicalName =
properties.wasJms/
@queueName
106

element
Migrated attributes
attribute
Resource with type

jmsQueue
'org.apache.activemq.command.ActiveMQQueue'
name = jndiName
id = jndiName
physicalName =
properties.wasJms/@topicName
Resource with type

'com.ibm.mq.jms.MQConnectionFactory'
name = jndiName
HOST or HOSTNAME =
properties.wmqJms/@hostName
PORT = properties.wmqJms/
@port
CHAN or CHANNEL =
properties.wmqJms/@channel
QMGR or QMANAGER =
properties.wmqJms/
@queueManager
TRAN or TRANSPORT =
properties.wmqJms/
@transportType
Resource with type

'com.ibm.mq.jms.MQQueueConnectionFactory'
jmsQueueConnectionFactory
name = jndiName
HOST or HOSTNAME =
@port
CHAN or CHANNEL =
QMGR or QMANAGER =
properties.wmqJms/
@queueManager
TRAN or TRANSPORT =
properties.wmqJms/
@transportType
Resource with type

'com.ibm.mq.jms.MQTopicConnectionFactory'
jmsTopicConnectionFactory
name = jndiName
HOST or HOSTNAME =
@port
CHAN or CHANNEL =
QMGR or QMANAGER =
properties.wmqJms/
@queueManager
TRAN or TRANSPORT =
properties.wmqJms/
@transportType
107

element
Migrated attributes
attribute
Resource with type 'com.ibm.mq.jms.MQTopic'
jmsTopic
name = jndiName
TOP or TOPIC =
properties.wmqJms/
@baseTopicName
Resource with type 'com.ibm.mq.jms.MQQueue'
jmsQueue
name = jndiName
QU or QUEUE =
properties.wmqJms/
@baseQueueName
Configuration elements that are migrated from the conf/context.xml file

The tool migrates elements from the Tomcat conf/context.xml file to the Liberty profile
migratedConfig/context.xml file.
Table 32. Configuration elements that are migrated from the conf/context.xml file
Liberty profile
configuration element
Migrated attributes
Tomcat attribute = Liberty
profile attribute
Manager with className

'org.apache.catalina.session.StandardManager'
httpSession
maxActiveSessions =
maxInMemorySessionCount
maxInactiveInterval =
invalidationTimeout
sessionIdLength = idLength
processExpiresFrequency =
forceInvalidationMultiple

dataSource
See the table about the

conf/server.xml file for
details on migrated
attributes.

dataSource

details on migrated
attributes.

dataSource

details on migrated
attributes.

dataSource

details on migrated
attributes.
Resource with type


details on migrated
attributes.
108
Table 32. Configuration elements that are migrated from the conf/context.xml file (continued)
Liberty profile
configuration element
Migrated attributes
Tomcat attribute = Liberty
profile attribute
Resource with type

jmsTopic

details on migrated
attributes.
Resource with type

jmsQueue

details on migrated
attributes.
Resource with type


details on migrated
attributes.
Resource with type

jmsQueueConnectionFactory See the table about the

details on migrated
attributes.
Resource with type


details on migrated
attributes.
jmsTopic

details on migrated
attributes.
jmsQueue

details on migrated
attributes.
Configuration elements that are migrated from the conf/web.xml file

The tool migrates elements from the Tomcat conf/web.xml file to the Liberty profile migratedConfig/
web.xml file.
Table 33. Configuration elements migrated from the conf/web.xml file
mime-mapping/extension and mime-mapping/mimetype

element
mimeTypes/type
Migrated elements
The Liberty mimeTypes/type
value is set to
extension=mime-type.
109
Configuration elements that are migrated from tomcat-users elements

The tool migrates tomcat-users elements from the Tomcat tomcat-users.xml file or a user-defined file
with tomcat-users elements to the Liberty profile migratedConfig/[tomcat-users-file]_users-androles.xml file, where tomcat-users-file is the name of the source Tomcat file.
Table 34. Configuration elements that are migrated from tomcat-users elements

element
Migrated attributes
attribute
tomcat-users/role
basicRegistry/group
rolename = name
tomcat-users/user
basicRegistry/user
username = name
password = password (hash
encoded using the
roles = group/
member[@name]
A group member is created for
each role.
Configuration elements that are migrated from the application

META-INF/context.xml file
The tool migrates Tomcat configuration elements from the application META-INF/context.xml file to the
Liberty profile migratedConfig/<application-name>/application-config-context.xml file.
Table 35. Configuration elements that are migrated from the application META-INF/context.xml file

element
Migrated attributes
attribute

dataSource

details on migrated attributes.

dataSource


dataSource


dataSource

Resource with type


Resource with type

jmsTopic

110
Table 35. Configuration elements that are migrated from the application META-INF/context.xml file (continued)

element
Migrated attributes
attribute
Resource with type

jmsQueue

Resource with type


Resource with type

jmsQueueConnectionFactory

Resource with type


jmsTopic

jmsQueue

Configuration elements that are migrated from the application

WEB-INF/web.xml file
The tool migrates Tomcat configuration elements from the application WEB-INF/web.xml file to the Liberty
profile migratedConfig/<application-name>/application-config-web.xml file.
Table 36. Configuration elements migrated from the application WEB-INF/web.xml file

element
Migrated attributes
attribute
web-app/security-constraint/auth-constraint
application/application-bnd/
security-role
role-name = name
111
112
Copyright and trademarks
Copyright IBM Corporation 2009, 2015.

The information contained in this publication is provided for informational purposes only. While efforts
were made to verify the completeness and accuracy of the information contained in this publication, it is
provided AS IS without warranty of any kind, express or implied. In addition, this information is based
on IBM's current product plans and strategy, which are subject to change by IBM without notice. IBM
shall not be responsible for any damages arising out of the use of, or otherwise related to, this
publication or any other materials. Nothing contained in this publication is intended to, nor shall have
the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering
the terms and conditions of the applicable license agreement governing the use of IBM software.
References in this publication to IBM products, programs, or services do not imply that they will be
available in all countries in which IBM operates. Product release dates and/or capabilities referenced in
this presentation may change at any time at IBM's sole discretion based on market opportunities or other
factors, and are not intended to be a commitment to future product or feature availability in any way.
Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that
any activities undertaken by you will result in any specific sales, revenue growth, savings or other
results.
Performance is based on measurements and projections using standard IBM benchmarks in a controlled
environment. The actual throughput or performance that any user will experience will vary depending
upon many factors, including considerations such as the amount of multiprogramming in the user's job
stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no
assurance can be given that an individual user will achieve results similar to those stated here.
IBM, the IBM logo, developerWorks, Passport Advantage, Rational, and WebSphere are trademarks of
International Business Machines Corporation in the United States, other countries or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or
its affiliates.
Other product and service names might be trademarks of IBM or other companies.
113
114
IBM
Printed in USA

MigrationToolkit en US 8.5.5.7

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MigrationToolkit en US 8.5.5.7

Uploaded by

Copyright:

Available Formats

WebSphere Application Server

IBM WebSphere Application Server

Appendix A. Cloud migration rules

Chapter 2. What's new . . . . . . ..

Chapter 4. Installing the migration tools

Chapter 6. Installing IBM WebSphere

Chapter 8. Shared Java projects . . ..

Chapter 9. Configuring a Java EE

Chapter 10. Migrating an application to

Chapter 11. Migrating Apache Tomcat

Migrating Apache Tomcat server configuration

Chapter 12. Troubleshooting . . . ..

Troubleshooting the application migration tools ..

Copyright IBM Corp. 2009, 2015

Java code review .

Appendix C. WAS Liberty migration

Appendix D. Java SE version migration 71

Appendix E. Third-party application

Appendix F. Migrated Apache Tomcat

Application Migration Tools

Configuration elements that are migrated

Copyright and trademarks . . . . ..

Cloud migration tool

WebSphere Version to Version Application Migration Tool

Third-party application migration tools

Application Migration Tools

Tomcat Configuration Migration Tool

WebSphere Configuration Migration Tool

Application Migration Tools

Chapter 2. What's new

Cloud Migration Tool

Liberty profile Java EE 7 behavior differences

Application Evaluation Report

Migration Toolkit for Application Binaries

Copyright IBM Corp. 2009, 2015

Application Migration Tools

Cloud Migration Tool

WebSphere Application Server Version Migration Tool

Third-party migration tools

Copyright IBM Corp. 2009, 2015

Application Migration Tools

Chapter 4. Installing the migration tools

Figure 1. Accessing the migration tool software from Eclipse Marketplace

v To install from the online repository:

1) In your IDE, go to Help > Install New Software.

Application Migration Tools

Figure 2. Selecting migration toolkit features

c. In the Install Details window, click Next.

Chapter 4. Installing the migration tools

Application Migration Tools

Chapter 5. Uninstalling the migration tools

Copyright IBM Corp. 2009, 2015

Application Migration Tools

Chapter 6. Installing IBM WebSphere Application Server

Copyright IBM Corp. 2009, 2015

Application Migration Tools

Chapter 7. Importing applications into the development

Figure 3. Importing an EAR file

Copyright IBM Corp. 2009, 2015

Application Migration Tools

Chapter 8. Shared Java projects

Figure 4. Java EE EAR module dependencies

4. Click OK to save your changes.

Web module library