Download IBM IBM WebSphere Application Server Migration Toolkit WebSphere Application Server

WebSphere Application Server
IBM WebSphere Application Server
Migration Toolkit
Version 9.0 Release 16.0.0.3
IBM
Contents
Chapter 1. Overview . . . . . . . . . 1
Chapter 2. What's new . . . . . . . . 5
Chapter 3. Support . . . . . . . . . . 7
Chapter 4. Installing the migration tools
9
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
Traditional Eclipse project organization .
Maven projects . . . . . . . . .
.
.
.
.
.
.
. 17
. 18
Chapter 8. Shared Java projects . . . . 19
EAR-level library .
Web module library
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 19
. 19
Chapter 9. Configuring a Java EE
Runtime Library . . . . . . . . . . . 21
Chapter 10. Migrating an application to
WebSphere Application Server . . . . 23
Configuring the application migration tool for
analysis. . . . . . . . . . . . . . .
Analyzing code for migration . . . . . . .
Rule Severity . . . . . . . . . . . . .
Displaying detailed help . . . . . . . . .
Application Evaluation Report . . . . . . .
Running additional rules to optimize code quality
.
.
.
.
.
23
27
30
30
31
32
Chapter 11. Migrating Apache Tomcat
configuration to Liberty . . . . . . . 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. . . . . . . . . . .
© Copyright IBM Corp. 2009, 2016
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
41
41
42
42
42
Troubleshooting the configuration migration tool .
Known issues. . . . . . . . . . . .
Appendix A. Cloud migration rules
. 45
. 46
. . 47
Appendix B. WebSphere
version-to-version migration rules and
quick fixes . . . . . . . . . . . . . 49
Java code review .
JSP code review . .
XML code review .
File review . . .
Deprecated features
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
53
54
56
56
Appendix C. Liberty migration rules . . 65
Rules for the Application Evaluation Report
Rules for migrating applications to Liberty .
.
.
.
.
. 65
. 68
Appendix D. Java EE version migration 71
Java EE 6 behavior differences .
Java EE 7 behavior differences .
.
.
.
.
.
.
.
.
.
.
.
.
. 71
. 71
Appendix E. Java SE version migration 75
J2SE 5.0 compatibility impacts . .
Java SE 6 compatibility impacts. .
Java SE 7 compatibility impacts. .
Java SE 8 compatibility impacts. .
Oracle to IBM compatibility impacts
Sun internal APIs . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
75
77
77
79
80
81
Appendix F. Third-party application
server migration rules and quick fixes . 83
WebLogic Server rules and quick fixes . . . . . 83
WebLogic Server Java code review rules . . . . 83
WebLogic Server JSP code review rules . . . . 87
WebLogic Server XML file review rules . . . . 87
WebLogic Server file review rules . . . . . . 90
JBoss Application Server rules and quick fixes . . . 91
JBoss Java code review rules. . . . . . . . 91
JBoss Application Server XML file review rules
92
JBoss Application Server file review rules . . . 93
Oracle Application Server rules and quick fixes . . 94
Oracle Application Server Java code review rules 94
Oracle Application Server JSP code review rules 95
Oracle Application Server XML file review rules 95
Oracle Application Server file review rules . . . 97
Apache Tomcat rules and quick fixes . . . . . . 97
Apache Tomcat Java code review rules . . . . 97
Apache Tomcat XML code review rules . . . . 98
Common rules for all application servers . . . . 99
Common rules for competitive migration rule sets
99
Framework migration . . . . . . . . . . 100
Framework XML - Spring best practices rules
100
Hibernate to WebSphere JPA migration . . . . . 101
iii
Hibernate to WebSphere JPA - Java rules .
Hibernate to WebSphere JPA - XML rules .
.
.
. 101
. 103
Appendix G. Migrated Apache Tomcat
configuration elements . . . . . . . 105
Configuration elements
conf/server.xml file .
Configuration elements
conf/context.xml file .
Configuration elements
conf/web.xml file . .
iv
that are
. . .
that are
. . .
that are
. . .
Application Migration Tools
migrated
. . .
migrated
. . .
migrated
. . .
from
. .
from
. .
from
. .
the
. . 105
the
. . 112
the
. . 113
Configuration elements that are migrated
tomcat-users elements . . . . . .
Configuration elements that are migrated
application META-INF/context.xml file.
Configuration elements that are migrated
application WEB-INF/web.xml file . .
from
. .
from
. .
from
. .
. . 113
the
. . 114
the
. . 115
Copyright and trademarks . . . . . . 117
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 WebSphere Application Server Liberty, and to cloud platforms such as Liberty on Bluemix
Instant Runtimes.
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.
v Cloud Migration Tool
v WebSphere Version to Version Application Migration Tool
v Apache Tomcat to Liberty 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 a 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 Application Server traditional or Liberty, Apache Tomcat Server,
JBoss Application Server, Oracle Application Server, or Oracle WebLogic Server to cloud runtime
environments such as IBM Bluemix Instant Runtimes, IBM Containers (Docker), WebSphere Application
Server on Cloud, and Liberty running on third-party PaaS runtime environments.
WebSphere Version to Version Application Migration Tool
The WebSphere Version to Version Application Migration Tool assists in migrating application source
code from older versions of WebSphere Application Server to WebSphere Application Server Version 8.5.5
and 9.0. It also helps you quickly and easily evaluate WebSphere Application Server traditional
applications for their readiness to run on Liberty or Liberty Core in both cloud and on-premises
environments. For information about how to generate this report, see “Application Evaluation Report” on
page 31.
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
© Copyright IBM Corp. 2009, 2016
1
4. Migrate the runtime configuration
5. Test applications with the new server configuration
6. Put the new server into production
The tool analyzes your application source code and highlights Java Platform, Enterprise Edition (Java EE)
programming model and WebSphere API differences between traditional WebSphere Application Server
versions and between the traditional and Liberty servers. Based on this analysis, the tool offers advice
and potential solutions to assess the ease of moving applications. 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 V6.0
v WebSphere Application Server V6.1
v WebSphere Application Server V7.0
v WebSphere Application Server V8.0
v WebSphere Application Server traditional V8.5.5
v WebSphere Application Server traditional V9.0
v WebSphere Application Server Liberty
v WebSphere Application Server Liberty Core
The tool supports migrating to the following versions:
v WebSphere Application Server traditional V8.5.5
v WebSphere Application Server traditional V9.0
v WebSphere Application Server Liberty
v WebSphere Application Server Liberty Core
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 8.5.5 or 9.0
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)
2
Application Migration Tools
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 Migrating Oracle Application Server Java and JSP artifacts (Java EE 5 and prior versions)
v Migrating Oracle Application Server deployment descriptors (Java EE 5 and prior versions)
v Migrating Apache Tomcat Java and JSP artifacts (Java EE 5 and prior versions)
v Migrating Apache Tomcat Context XML information contained in the application
v Migrating from Apache Tomcat 6.0 or 7.0
v Migrating from Java SE 1.4, 5, 6, or 7 to either Java 6, 7, or 8.
Tomcat Configuration Migration Tool
The Configuration Migration Tool helps you move server and application configuration to WebSphere
Application Server Liberty by automatically migrating portions of the configuration. The tool supports:
v Migrating from Apache Tomcat 6.0 or 7.0
v Migrating to Liberty
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 Application Server V7.0 or later, WebLogic, or JBoss and
creates equivalent resources for WebSphere Application Server Liberty. It can optionally create a Jython
script that you can use to create equivalent resources in traditional WebSphere Application Server.
You can install WCMT from the migration toolkit online repository or download it separately from the
WASdev website, https://developer.ibm.com/wasdev/downloads/#asset/toolsWebSphere_Configuration_Migration_Tool.
The WCMT tool is available in English only.
Additional Resources
With the Migration Toolkit for Application Binaries, you can produce migration reports from the
command line using the application archives and class files without the need for source code. This tool
highlights the Java SE differences, deprecations and removals, Java EE programming model differences,
and WebSphere API differences between traditional WebSphere from V6.1 to V9.0 and between traditional
WebSphere and Liberty servers. It also supports the cloud migration scenarios and includes a
module-based cloud connectivity summary.
The binary scan tool supports migrating from the following versions:
v WebSphere Application Server V6.1
v WebSphere Application Server V7.0
v WebSphere Application Server V8.0
v WebSphere Application Server traditional V8.5.5
v WebSphere Application Server traditional V9.0
v WebSphere Application Server Liberty
v WebSphere Application Server Liberty Core
It supports migrating to the following versions:
v WebSphere Application Server traditional V8.5.5
Chapter 1. Overview
3
v WebSphere Application Server traditional V9.0
v WebSphere Application Server Liberty
v WebSphere Application Server Liberty Core
Download the Migration Toolkit for Application Binaries from https://developer.ibm.com/wasdev/
downloads/#asset/tools-Migration_Toolkit_for_Application_Binaries
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.
The WASdev Migration page provides an overview of all the tools, videos, and resource links.
The Knowledge Collection: Migration planning for WebSphere Application Server provides information
on all aspects of WebSphere Application Server 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.
4
Application Migration Tools
Chapter 2. What's new
New support in the binary scanner
Most of the functional enhancements this release were in the binary scanner. Check out the new
capabilities in the command line tool including:
v A new application inventory report
v Rule severity information in the detailed analysis report that matches the rule severity in the Eclipse
tool
v JSON output for all reports
v Support for migrating from WebSphere V6.1 including Java SE 5 rules
A few new rules
Rules were added to inform you of migration considerations related to:
v Java considerations for the WebSphere 8.5.5 ejbdeploy command
v OpenJPA property strings in Java code
v WOLA support changes in Liberty
v New eXtreme Scale data cache support
Removed support to select WebSphere Application Server V7.0 and V8.0 as the
target application server
Migrating to releases prior to WebSphere V8.5.5 is not strategic because of our recent end of support
announcement for WebSphere Application Server V7, WebSphere Application Server V8, and Java SE 6.
While the tool no longer supports choosing WebSphere V7.0 or V8.0 as a target, the V7.0 and V8.0 related
rules are still included when migrating from earlier versions of WebSphere to V8.5.5 and later.
Support
Bug and field support fixes were added to this release.
© Copyright IBM Corp. 2009, 2016
5
6
Application Migration Tools
Chapter 3. Support
Supported platforms
The migration tools are supported on the following Eclipse-based platforms:
v Eclipse Luna (4.4), Mars (4.5), and Neon (4.6)
v Rational Application Developer versions 9.0 to 9.5
v Rational Software Architect versions 9.0 to 9.5
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, 8.0, or 8.5.5 to WebSphere Application Server
Version 8.5.5 or 9.0. It also scans for known issues in applications being migrated from WebSphere
Application Server traditional to 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, “Liberty migration rules,” on page 65
v Appendix D, “Java EE version migration,” on page 71
v Appendix E, “Java SE version migration,” on page 75
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 83
v “JBoss Application Server rules and quick fixes” on page 91
v “Oracle Application Server rules and quick fixes” on page 94
v “Apache Tomcat rules and quick fixes” on page 97
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 Liberty. For information about which configuration elements are
migrated, see Appendix G, “Migrated Apache Tomcat configuration elements,” on page 105.
© Copyright IBM Corp. 2009, 2016
7
Getting assistance
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.
8
Application Migration Tools
Chapter 4. Installing the migration tools
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 required 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.6: Neon - http://download.eclipse.org/releases/neon
v Eclipse 4.5: Mars - http://download.eclipse.org/releases/mars
v Eclipse 4.4: Luna - http://download.eclipse.org/releases/luna
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.
If you are installing the toolkit on a machine that is not connected to the Internet, you can use a
connected machine to download Eclipse, the migration tools, and the BIRT Framework. Download the
BIRT Framework from http://download.eclipse.org/birt/downloads/ and verify that you have any
prerequisites for the BIRT Framework. Extract Eclipse and the BIRT Framework and its prerequisites
to the same folder, and then start the IDE and install the migration tools.
4. Install the migration tool features that you need.
a. Access the migration tool software. You can install the tool directly from our online repository or
from Eclipse Marketplace. Alternatively, you can manually download and install the repository
archive.
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 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.
© Copyright IBM Corp. 2009, 2016
9
Figure 1. Accessing the migration tool software from Eclipse Marketplace
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://developer.ibm.com/wasdev/downloads/#asset/toolsWebSphere_Application_Server_Migration_Toolkit.
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
Application Migration Tools
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.
Chapter 4. Installing the migration tools
11
12
Application Migration Tools
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.
© Copyright IBM Corp. 2009, 2016
13
14
Application Migration Tools
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 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 WebSphere Application Server traditional and Liberty.
v IBM WebSphere Application Server Liberty Developer Tools
v IBM WebSphere Application Server V9.0 Developer Tools
v IBM WebSphere Application Server V8.5 Developer Tools
v IBM WebSphere Application Server V8.0 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.
© Copyright IBM Corp. 2009, 2016
15
16
Application Migration Tools
Chapter 7. Importing applications into the development
environment
Traditional Eclipse project organization
To analyze application source code for migration, the application must be imported into your
Eclipse-based IDE. The application modules must be organized in projects that reflect their structure as
EAR, web archive (WAR), and Enterprise JavaBeans (EJB) files. Specifically, some migration quick fixes
that change web and EJB bindings and extensions only work when analyzing projects with the proper
project facets to indicate they contain code for dynamic web modules and EJB modules.
If your files are not already in Eclipse, 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:
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
© Copyright IBM Corp. 2009, 2016
17
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).
Maven projects
To effectively analyze an application that uses Maven, install the latest M2Eclipse (m2e) in your Eclipse
environment. WebSphere Developer Tools (WDT) and Rational Application Developer include m2e in the
installation package. For some of the migration quick fixes to run correctly, the appropriate facets need to
be set on the projects. For example, a web project requires the dynamic web module facet, and an EJB
project requires the EJB module facet. Any newly created project in an IDE with m2e installed is
automatically created with the appropriate facets when the proper archetype is chosen. When you import
Maven projects that were not created in an environment with m2e, check the project to see whether the
appropriate facets are set. To verify the facets, right-click on the project and navigate to Properties >
Project Facet. You might run into a window with a similar message to Figure 4.
Figure 4. Convert to facet
Select the Convert to facet form option to go to the correct project facet view. Select the correct facet for
web projects and EJB projects.
18
Application Migration Tools
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 5. 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.
© Copyright IBM Corp. 2009, 2016
19
20
Application Migration Tools
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 6. Server Runtime Environments pane
3. Click Add. Select IBM and the appropriate WebSphere Application Server for the target application
server. The choices available depend on the WebSphere Developer Tools or Rational Application
Developer features you have installed.
4. On the next wizard pages, configure your installed server location or install a new Liberty server.
5. Alternatively, click Add. Select Basic > J2EE Runtime Library.
6. 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 WebSphere Application Server traditional or Liberty 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
© Copyright IBM Corp. 2009, 2016
21
Targeted Runtimes, then select the recently configured Java EE runtime library, and click OK.
Figure 7. Targeted Runtimes
22
Application Migration Tools
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 (
Configurations.
) and select Software Analyzer
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 8. Creating a Software Analyzer configuration
2. In the configurations list, select Software Analyzer. Then, click New
changes to show the basic configuration interface.
© Copyright IBM Corp. 2009, 2016
. The right side of the window
23
Figure 9. 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 . 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
Application Migration Tools
Figure 10. 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 XML 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 11. 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 traditional, Liberty, or
Liberty Core.
Target Java EE version
When migrating to WebSphere Application Server Liberty, you can also select the target Java
Platform, Enterprise Edition (Java EE) version that you plan to use for the application.
If you move to the latest Java EE level on Liberty or traditional WebSphere Application Server
V9.0, 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 to Java EE 7 on either WebSphere Application Server traditional or Liberty. If you are
already on Liberty Java EE 6, you can stay on your current Java EE level with zero migration.
For Liberty, choose only the technologies that you are using. For example, if you do not use
the CDI feature, do not select CDI. For both Liberty and traditional WebSphere, choose only
the technologies that you must migrate. Some technologies, such as JPA and JAX-RS, do not
require moving to the latest Java EE level. Consider keeping existing JPA applications running
on the Java EE 6 JPA 2.0 feature based on OpenJPA, and use JPA 2.1 based on EclipseLink for
new applications.
Target cloud runtime
The target cloud runtime indicates the cloud platform that you are migrating to. You can
choose a cloud runtime environment to evaluate if your target application server is
WebSphere Application Server traditional V8.5.5 or V9.0, Liberty, or Liberty Core.
Source Java version
The source Java version indicates the Java Platform, Standard Edition (Java SE) version that
your application server currently uses.
26
Application Migration Tools
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 12. Rule properties
Analyzing code for migration
Run the analysis and display the results.
Chapter 10. Migrating an application to WebSphere Application Server
27
To start the analysis, click Analyze in the Software Analyzer Configuration window. The results are
displayed in the Software Analysis Results view.
Figure 13. 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 XML 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
Application Migration Tools
Figure 14. 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.
v
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.
Chapter 10. Migrating an application to WebSphere Application Server
29
Figure 15. Previewing quick fixes for multiple files
v
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.
Quick Fix All - This option resolves all issues identified for a given rule.
v
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.
Rule Severity
The rule severity helps identify the impact of an issue on your application migration.
Rule severity
Source scanner Binary scanner
icon
icon
Description
Severe
Severe rules indicate an API removal or behavior change that
can break the application and must be addressed.
Warning
Warning rules indicate behavior changes that might break the
application and should be evaluated.
Information
Information rules indicate the use of deprecated APIs or minor
behavior changes that will not affect most applications.
Displaying detailed help
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.
To open the Help view if it is not already displayed:
On Windows:
v Press F1
On Linux:
v Press Shift-F1
30
Application Migration Tools
On Mac:
v From the rule set dialog window, select the
in lower left corner.
v From the results view, select Window > Show View > Other... > Help > OK
Application Evaluation Report
With any of the migration tools installed, you 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 generate the report:
1. Click Run > Generate Application Evaluation Report.
2. Select the projects that you want to evaluate.
3. Select the WebSphere products you want to compare.
4. Click OK.
Figure 16. Application Evaluation Report
The rows in the report vary depending on the application.
Chapter 10. Migrating an application to WebSphere Application Server
31
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 17 shows examples of the additional rules.
Figure 17. 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.
Some users 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
Application Migration Tools
Chapter 11. Migrating Apache Tomcat configuration to Liberty
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 server must already exist in Eclipse. To create a
Liberty server in Eclipse, you must use the WebSphere Application Server Liberty Developer 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 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 server
configuration and the server migration log file, and click OK. The Liberty server workspace refreshes.
The selected Liberty 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 server configuration file that was
updated to include the generated
configuration file, migratedConfig/serverupdates-for-config.xml
migratedConfig/configMigration.log
Information on the migration
migratedConfig/context.xml
Configuration from the Tomcat context.xml
file
migratedConfig/server.xml
Configuration from the Tomcat server.xml
file
© Copyright IBM Corp. 2009, 2016
33
File name
Description
migratedConfig/server.xml.original.txt
Copy of the original Liberty 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 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
Configuration from the Tomcat
tomcat-users.xml file or a user-defined file
with tomcat-users elements. The Liberty 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 WebSphere Application Server Liberty 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
Application Migration Tools
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 server
configuration and the application migration log file, and click OK. The Liberty server workspace
refreshes.
The selected Liberty 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 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 Liberty
35
File name
Description
migratedConfig/[application-name]/server.xml.original.txt
Copy of the original Liberty 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 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.
Completing the generated configuration
After the tool migrates the Apache Tomcat server and application configuration to WebSphere
Application Server Liberty, 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
Liberty 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 messaging features and related configuration elements in the Liberty
server. The applications must use JMS interfaces to function properly when configured to use the Liberty
embedded messaging engine.
Migrating JMS Resource elements for WebSphere MQ
Tomcat Resource elements related to WebSphere MQ are migrated to Liberty WebSphere MQ
configuration elements. To connect to WebSphere MQ from Liberty, you must use the WebSphere MQ
resource adapter, which must be installed separately. For more information about installing the
WebSphere MQ resource adapter for WebSphere Application Server Liberty, see http://www.ibm.com/
support/docview.wss?uid=swg21633761.
36
Application Migration Tools
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 server 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 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 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
Chapter 11. Migrating Apache Tomcat configuration to Liberty
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 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 application-bnd security-role and group elements.
v allRolesMode="authOnly" - A Liberty 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
Application Migration Tools
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 Liberty. 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
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
server, or modify the configuration to not reference the variable.
WebSphere Application Server Liberty 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 server interprets the value
differently than Tomcat. The Liberty 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 server
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 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 server in the migratedConfig/server.xml
file. You can select a virtual host for your application when you migrate the application.
Chapter 11. Migrating Apache Tomcat configuration to Liberty
39
40
Application Migration Tools
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 18. 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:
© Copyright IBM Corp. 2009, 2016
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 19. 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
Application Migration Tools
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.
Chapter 12. Troubleshooting
43
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
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. The detailed
help for some cloud migration rules contain links to Bluemix support pages that might return 500
internal server error when rendered in a Linux Eclipse help window. This technique to view external
links in a browser can be used to workaround this problem.
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.
44
Application Migration Tools
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.
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 Server Selection window
The list of servers in the Liberty Server Selection window is populated with WebSphere Application
Server Liberty servers found in the Servers view of Eclipse. If no Liberty servers are present, no servers
are listed. Cancel the migration, add a Liberty 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 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 Configuration Editor to change and hash
encode the password attributes in the migrated configuration to the original unencrypted values from the
Tomcat server.
Chapter 12. Troubleshooting
45
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 server, there might be one or more basicRegistry elements with differing id attribute values.
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 WebSphere Application Server Liberty V8.5.5.2. Previous
versions of the Liberty server ignore hostAlias elements, and you can ignore the warning.
An application that runs on Liberty V8.5.5.2 does not persist session information
in Mozilla Firefox
After you migrate configuration for applications that require multiple cookies to Liberty V8.5.5.2, 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 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 migratedConfig/context.xml file.
46
Application Migration Tools
Appendix A. Cloud migration rules
The Cloud Migration Tool identifies application issues to consider when you move an application to
cloud platforms such as Bluemix Instant Runtimes (Cloud Foundry), Third-party PaaS (CF, OSE, etc.),
Docker (IBM Containers), and WebSphere on Cloud (virtual machines).
Liberty on Bluemix Instant Runtimes
The following rule is relevant only when migrating applications to Liberty for Java on IBM Bluemix.
v Optimized Java Runtime Environment
v An eXtreme Scale distributed in-memory cache is available
Liberty on Bluemix Instant Runtimes or third-party platforms (PaaS)
The following rules are relevant when migrating applications to Liberty for Java on IBM Bluemix or to WebSphere
Application Server Liberty on third-party cloud platform as a service (PaaS) environments
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 older or non-standard protocols
v HTTP session persistence
v Listening for inbound connections
v Stopping the Liberty server
v Two-phase commit transactions
Liberty on third-party platforms (PaaS)
The following rule is relevant when migrating applications to WebSphere Application Server Liberty on third-party
cloud platform as a service (PaaS) offerings.
v Transport security is terminated at the router
Connectivity considerations for IBM Cloud
The connectivity rules evaluate your application's use of the following resources that might have connectivity
considerations when moving applications to the cloud. These rules are flagged only once per Eclipse project (or Java
archive) to indicate the individual technologies that are used.
v Databases
v Enterprise Information Systems (EIS)
v Java EE security
v JavaMail server
v Java Message Service (JMS)
v Message-Driven Beans (MDB)
v Remote EJB lookups
v Remote EJB providers
v Remote web services
v Third-party security
v Vendor specific messaging
The following rule flags all URLs that might be affected by cloud migration:
v Validate the URL host and port for cloud access
© Copyright IBM Corp. 2009, 2016
47
Docker (IBM Containers)
The following rule is relevant when migrating applications to WebSphere Application Server traditional or Liberty
on Docker (IBM Containers).
v Managing data inside and between Docker containers
48
Application Migration Tools
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 20. Analysis domains
When you select the WebSphere Application Server Version Migration rule set, rules common to all
application servers and relevant WebSphere version migration rules will be selected. The common rules
for all application servers are described in “Common rules for all application servers” on page 99.
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, 8.0, and 8.5.5 to Version 8.0, 8.5.5,
or 9.0. To learn how to get more information about a rule, see “Displaying detailed help” on page 30.
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.
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.
© Copyright IBM Corp. 2009, 2016
49
Table 1. V5.1 to V6.0 migration (continued)
Rule Name
Quick Fix Action Taken
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
interfaces that were removed in WebSphere Application
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
that were removed in WebSphere Application Server V6.0.
Do not use security features that were
removed
No
This rule flags the use of the security classes and interfaces
that were removed in WebSphere Application Server V6.0.
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
interfaces that were removed in WebSphere Application
Server V6.0.
Table 2. V6.0 to V6.1 migration
Rule Name
Quick Fix Action Taken
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
removed in WebSphere Application Server V6.1.
Use the open source Mozilla Rhino
implementation instead of the removed
implementation
No
This rule flags the use of the Rhino packages that were
removed in WebSphere Application Server V6.1.
Use the UserRegistry interface instead of No
the CustomRegistry interface
50
Application Migration Tools
This rule flags the use of the CustomRegistry interface that
was removed in WebSphere Application Server V6.1.
Table 3. V6.1 to V7.0 migration
Rule Name
Quick Fix Action Taken
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.
Use MicrosoftSQLServerDataStore helper Yes
class instead of the
MSSQLDataStoreHelper class
Do not use the com.ibm.websphere.rsadapter.
MSSQLDataStoreHelper class because it was removed.
The quick fix changes the code to use
com.ibm.websphere.rsadapter.
MicrosoftSQLServerDataStoreHelper instead.
Appendix B. WebSphere version-to-version migration rules and quick fixes
51
Table 4. V7.0 to V8.0 migration
Rule Name
Quick Fix Action Taken
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.
Check for a behavior change in
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.
Check for a behavior change on
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().
Check for a behavior change on
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.
Check for a behavior change on the SIP
URI clone method
No
This rule flags the SIP URI clone method because it might
throw an exception if the application was compiled with
WebSphere Application Server V7.0 or with SIP Servlets 1.0
interfaces.
To resolve the exception, recompile the application with
WebSphere Application Server V7.0 and the CEA feature pack
or with WebSphere Application Server V8.0 and later.
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.
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.
52
Application Migration Tools
Table 5. V7.0 to V8.0 or V8.5 migration
Rule Name
Quick Fix Action Taken
Check for a behavior change in Java
Server Faces (JSF) Applications
No
This rule flags Java Server Faces (JSF) applications because
the default implementation for JSF container has changed in
WebSphere V8.0.
Table 6. V8.0, V8.5 and V9.0 migration
Rule Name
Quick Fix Action Taken
The Apache HTTP client API was
removed
No
This rule flags the use of the Apache HTTP client API that
was removed in WebSphere Application Server V8.0, V8.5,
and V9.0.
Table 7. V8.0 to V8.5 migration
Rule Name
Quick Fix Action Taken
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.
Table 8. V8.5 to V9.0 migration
Rule Name
Quick Fix Action Taken
SCA was removed
No
This rule flags the use of Service Component Architecture
(SCA) in applications. SCA was removed in WebSphere
Application Server V9.0.
The CDI OpenWebBeans API was
removed
No
This rule flags the use of the Apache OpenWebBeans API that
was removed in WebSphere Application Server V9.0.
The CEA system application
commsvc.ear was removed
No
This rule flags use of the Communications Enabled
Applications (CEA) REST interface that was provided by the
CEA system application commsvc.ear. The commsvc.ear
system application was removed in WebSphere Application
Server V9.0.
The Common Event Infrastructure API
was removed
No
This rule flags the use of packages from the Common Event
Infrastructure API that was removed.
The JSF SunRI engine was removed
No
This rule flags references to the com.sun.faces package.
JSP code review
Under the JSP code review set, the WebSphere version migration category has rules described in the
following table. To learn how to get more information about a rule, see “Displaying detailed help” on
page 30.
Note: JSP pages written in XML syntax (JSP documents) are not supported.
Appendix B. WebSphere version-to-version migration rules and quick fixes
53
Table 9. Migrating from Version 5.1
Rule Name
Quick Fix Action Taken
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.
Table 10. V6.1 to V7.0 migration
Rule Name
Quick Fix Action Taken
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.
Table 11. V7.0 to V8.0 migration
Rule Name
Quick Fix Action Taken
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.
Table 12. V6.1 to V7.0 migration
Rule Name
Quick Fix Action Taken
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.
54
Application Migration Tools
Table 12. V6.1 to V7.0 migration (continued)
Rule Name
Quick Fix Action Taken
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.
Table 13. V7.0 to V8.0 migration
Rule Name
Quick Fix Action Taken
Check for a behavior change for EJB
presence in a web module
No
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).
Check for a behavior change in
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 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.
Table 14. V7.0 to V8.0 or V8.5 migration
Rule Name
Quick Fix Action Taken
Check for a behavior change in Java
Server Faces (JSF) Applications
No
This rule flags Java Server Faces (JSF) applications because
the default implementation for JSF container has changed in
WebSphere V8.0.
Appendix B. WebSphere version-to-version migration rules and quick fixes
55
Table 15. V8.0 to V8.5 migration
Rule Name
Quick Fix Action Taken
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 Java rule to detect this
behavior change.
Check for a behavior change in JPA
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.
The ejbdeploy command is supported
with Java 6 and 7
No
When migrating to WebSphere V8.5.5 with Java 8, there is a
limitation that the ejbdeploy command must be run using
Java 6 or 7.
Table 16. V8.5 to V9.0 migration
Rule Name
Quick Fix Action Taken
SCA was removed
No
This rule flags the use of Service Component Architecture
(SCA) in applications. SCA was removed in WebSphere
Application Server V9.0.
The JSF SunRI engine was removed
No
This rule flags references to the JSF SunRI in XML files.
File review
The file review rules analyzes issues in files other than Java, XML, JSP in your application.
Table 17. V7.0 to V8.0 migration
Rule Name
Quick Fix Action Taken
Check for a behavior change for EJB
presence in a web module
No
This rule scans JAR files your in WEB-INF/lib folder to see if
any EJB annotations or deployment descriptors are detected.
Table 18. V8.5 to V9.0 migration
Rule Name
Quick Fix Action Taken
SCA was removed
No
This rule flags the use of Service Component Architecture
(SCA) in applications. SCA was removed in WebSphere
Application Server V9.0.
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 Deprecated before V8.0 and removed in V8.0
v Deprecated before V8.0
v Deprecated in V8.0
v Deprecated in V8.5
56
Application Migration Tools
v Deprecated in V8.5 and removed in V9.0
v Deprecated in V9.0
Table 19. Java deprecated features - Deprecated before V8.0 and removed in V8.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 20. Java deprecated features - Deprecated before 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.
Avoid using the deprecated
AppDeploymentController methods
No
This rule flags the use of the application deployment controller
getTaskInfo methods.
Avoid using the deprecated
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.
Avoid using the deprecated
application management
installStandaloneRAR method
No
This rule flags the use of the application management
installStandaloneRAR method.
Avoid using the deprecated
application management
moveModule method
No
This rule flags the use of the application management
moveModule method.
Avoid using the deprecated
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.
Avoid using the deprecated
com.ibm.etools.logging utilities
No
This rule detects and flags references to com.ibm.etools.logging
packages that are deprecated.
Avoid using the deprecated
command manager methods
Yes
This rule flags the use of the deprecated methods in
com.ibm.websphere.management.cmdframework.
CommandMgrInitializer class.
The quick fix changes the methods to the recommended
replacements.
Appendix B. WebSphere version-to-version migration rules and quick fixes
57
Table 20. Java deprecated features - Deprecated before V8.0 (continued)
Rule Name
Quick
Fix
Action Taken
Avoid using the deprecated
ConnectionFactory MBean methods
No
This rule flags the deprecated ConnectionFactory MBean
operations getPoolContents, getAllPoolContents, and
showAllocationHandleList.
Avoid using the deprecated
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.
Avoid using the deprecated
Connector Architecture interfaces
No
This rule flags the deprecated Connector Architecture interfaces
com.ibm.websphere.j2c. ConnectionEventListener and
com.ibm.websphere.j2c.ConnectionManager.
Avoid using the deprecated
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.
Avoid using the deprecated
DumpNameSpace constructor and
fields
No
This rule flags the use of the deprecated constructor and fields
from the com.ibm.websphere.naming.DumpNameSpace class.
Avoid using the deprecated
DynamicCacheAccessor methods
No
This rule flags the use of the deprecated methods from the
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.
Avoid using the deprecated
ExtendedJTATransaction method
registerSynchronizationCallbackFor
CurrentTran
No
This rule detects and flags the method
registerSynchronizationCallbackFor CurrentTran from the class
ExtendedJTATransaction.
Avoid using the deprecated
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.
Avoid using the deprecated
LocalHomeAccessor class
No
This rule flags the use of the com.ibm.websphere.ejbcontainer.
LocalHomeAccessor class.
Avoid using the deprecated
management
InvalidDocumentURIException class
Yes
This rule flags the use of the
com.ibm.websphere.management.exception.
InvalidDocumentURIException class.
The quick fix changes the code to use
DocumentNotFoundException.
Avoid using the deprecated
management NestedAdminException
class
58
Application Migration Tools
No
This rule flags the use of the
com.ibm.websphere.management.exception.
NestedAdminException class.
Table 20. Java deprecated features - Deprecated before V8.0 (continued)
Rule Name
Quick
Fix
Action Taken
Avoid using the deprecated
management NotificationConstants
TYPE_AGENT_DISCOVERED field
Yes
This rule flags the use of the
NotificationConstants.TYPE_AGENT_DISCOVERED field.
Avoid using the deprecated
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.
Avoid using the deprecated
management statistics interfaces
Yes
This rule flags the use of the
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.
The quick fix changes the methods to the recommended
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.
Avoid using the deprecated
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.
Avoid using the deprecated
No
PmiDataInfo getParticipation method
This rule flags the use of the
com.ibm.websphere.pmi.PmiDataInfo. getParticipation() method.
Avoid using the deprecated PMI
dynamic cache
OBJECT_CACHE_GROUP field
This rule flags the use of the deprecated
com.ibm.websphere.pmi.stat.
WSDynamicCacheStats.OBJECT_CACHE_GROUP field.
Yes
The quick fix changes OBJECT_CACHE_GROUP to
OBJECT_GROUP.
Avoid using the deprecated PMI
dynamic cache
SERVLET_CACHE_GROUP field
No
This rule flags the use of the deprecated
com.ibm.websphere.pmi.stat.
WSDynamicCacheStats.SERVLET_CACHE_GROUP field.
Avoid using the deprecated
PmiJmxTest methods
No
This rule flags the use of the deprecated methods from the
com.ibm.websphere.pmi.PmiJmxTest class.
Avoid using the deprecated PMI
MBeanLevelSpec methods
No
This rule flags the use of the deprecated constructors and
methods from the com.ibm.websphere.pmi.stat.MBeanLevelSpec
class.
Avoid using the deprecated
PmiModuleConfig print method
No
This rule flags the use of the deprecated
com.ibm.websphere.pmi.PmiModuleConfig. print(PrintWriter)
method.
Avoid using the deprecated PMI
StatDescriptor methods
No
This rule flags the use of the deprecated constructor and methods
from the com.ibm.websphere.pmi.stat.StatDescriptor class.
Appendix B. WebSphere version-to-version migration rules and quick fixes
59
Table 20. Java deprecated features - Deprecated before V8.0 (continued)
Rule Name
Quick
Fix
Action Taken
Avoid using the deprecated PMI
statistic classes
No
This rule flags the use of the deprecated classes from the
com.ibm.websphere.pmi.stat package.
Avoid using the deprecated PMI
WSStats methods
No
This rule flags the use of the deprecated methods from the
com.ibm.websphere.pmi.stat.WSStats interface.
Avoid using the deprecated
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.
Avoid using the deprecated resource
adapter fields
No
This rule flags the use of the deprecated resource adapter fields.
Avoid using the deprecated resource
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
This rule flags the use of the deprecated methods from the
com.ibm.websphere.scheduler.MessageTaskInfo class.
Avoid using the deprecated
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.
Avoid using the deprecated security
authentication WSPrincipal
getCredential method
No
This rule flags the use of the deprecated getCredential() method
from the com.ibm.websphere.security.auth.WSPrincipal class.
Avoid using the deprecated security
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.
Avoid using the deprecated security
LoginHelper class
No
This rule flags the use of the deprecated
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.
Avoid using the deprecated servlet
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.
Avoid using the deprecated servlet
cache MetaDataGenerator initialize
method
No
This rule flags the use of the deprecated initialize() method from
the com.ibm.websphere.servlet.cache. MetaDataGenerator class.
Avoid using the deprecated
SIMediationBeanMessageContext
interface
No
This rule flags the use of the deprecated
com.ibm.websphere.sib.mediation.
messagecontext.SIMediationBeanMessageContext interface.
Avoid using the deprecated
SIMessageContextException class
Yes
This rule flags the use of the deprecated
com.ibm.websphere.sib.mediation.handler.
SIMessageContextException class.
The quick fix changes the code to use MessageContextException
instead.
60
Application Migration Tools
Table 20. Java deprecated features - Deprecated before V8.0 (continued)
Rule Name
Quick
Fix
Action Taken
Avoid using the deprecated
TransactionControl interface
No
This rule flags the use of the deprecated
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.
Avoid using the deprecated
UNTGenerateCallback methods
Yes
This rule flags the use of the deprecated methods from the
com.ibm.websphere.wssecurity.
callbackhandler.UNTGenerateCallback class.
The quick fix changes the methods to the recommended
replacements.
Avoid using the deprecated
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.
Avoid using the deprecated
WebContainer MBean operations
No
This rule flags references to the deprecated WebContainer MBean
operations startTransports, stopTransports, and
restartWebApplication.
Avoid using the deprecated
WebSphere Ant class
ModuleValidator
No
This rule flags the use of the deprecated WebSphere Ant class
com.ibm.websphere.ant.tasks. ModuleValidator.
Avoid using the deprecated
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.
Avoid using the deprecated
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.
Avoid using the deprecated
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.
Table 21. Java deprecated features - Migration to V8.0
Rule Name
Quick
Fix
Action Taken
Avoid extending the
AppDeploymentTask class
No
This rule flags any class that extends
com.ibm.websphere.management.application.
client.AppDeploymentTask.
Avoid using the deprecated
AppConstants fields
No
This rule flags the use of the deprecated fields from the
com.ibm.websphere.management.application. AppConstants class.
Avoid using the deprecated
AppManagementBaseFactory
methods
No
This rule flags the use of the deprecated methods from the
com.ibm.websphere.management.application.
AppManagementBaseFactory class.
Avoid using the deprecated
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.
Appendix B. WebSphere version-to-version migration rules and quick fixes
61
Table 21. Java deprecated features - Migration to V8.0 (continued)
Rule Name
Quick
Fix
Action Taken
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.
Avoid using the deprecated
WASDirectory methods and fields
No
This rule flags the deprecated
com.ibm.websphere.product.WASDirectory methods and related
fields.
Avoid using the deprecated
WebSphere Studio Application
Developer Integration Edition
libraries
No
This rule flags the use of the deprecated WebSphere Studio
Application Developer Integration Edition libraries.
Table 22. Java deprecated features - Deprecated in V8.5 and removed in V9.0
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.
Avoid using the deprecated CEA
system application commsvc.ear
This rule flags use of the Communications Enabled Applications
(CEA) REST interface provided by the deprecated CEA system
application commsvc.ear.
No
Table 23. Java deprecated features - Deprecated in V8.5
Rule Name
Avoid using the deprecated
WSSecurityHelper
getLTPACookieFromSSOToken
method
Quick
Fix
Yes
Avoid using the deprecated
Yes
WSSecurityHelper revokeSSOCookies
method
Action Taken
This rule flags the deprecated
com.ibm.websphere.security.WSSecurityHelper
getLTPACookieFromSSOToken method.
This rule flags the deprecated
com.ibm.websphere.security.WSSecurityHelper revokeSSOCookies
method.
Table 24. Java deprecated features - Deprecated in V9.0
Rule Name
Quick
Fix
Action Taken
The CommonJ Timer and Work
Manager APIs are deprecated
No
This rule flags references to the CommonJ Timer and Work
Manager APIs. They are deprecated in WebSphere Application
Server traditional V9.0.
The optional Java EE 7 technology
Java API for XML-based RPC
(JAX-RPC) 1.1 is deprecated
No
The Java EE 7 technology for XML-based RPC (JAX-RPC) 1.1 is
deprecated in WebSphere Application Server traditional V9.0.
62
Application Migration Tools
Table 24. Java deprecated features - Deprecated in V9.0 (continued)
Rule Name
Quick
Fix
Action Taken
The optional Java EE 7 technology
Java API for XML Registries (JAXR)
1.0 is deprecated
No
The Java EE 7 technology for XML Registries (JAXR) 1.0 is
deprecated in WebSphere Application Server traditional V9.0.
The optional Java EE 7 technology
Java EE Application Deployment 1.2
is deprecated
No
The Java EE 7 technology Java EE Application Deployment 1.2 is
deprecated in WebSphere Application Server traditional V9.0.
The WebSphere Asynchronous Beans
API is deprecated
No
This rule flags use of the com.ibm.websphere.asyncbeans API. It
is deprecated in WebSphere Application Server traditional V9.0.
Table 25. JSP file deprecated features - Deprecated before 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 26. XML file deprecated features - Deprecated before V8.0
Rule Name
Quick
Fix
Action Taken
Avoid using the deprecated
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).
Table 27. XML file deprecated features - Deprecated in V9.0
Rule Name
Quick
Fix
Action Taken
The optional Java EE 7 technology
Enterprise JavaBeans (EJB) entity
beans is deprecated
No
This rule flags entity elements in ejb-jar.xml files. The Enterprise
JavaBeans (EJB) entity beans technology is deprecated in
WebSphere Application Server traditional V9.0.
The optional Java EE 7 technology
Java API for XML-based RPC
(JAX-RPC) 1.1 is deprecated
No
The Java EE 7 technology for XML-based RPC (JAX-RPC) 1.1 is
deprecated in WebSphere Application Server traditional V9.0.
Appendix B. WebSphere version-to-version migration rules and quick fixes
63
64
Application Migration Tools
Appendix C. Liberty migration rules
The 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 28. Java technologies in WebSphere Application Server platforms
Web services technologies
Bluemix
Liberty Core
Liberty
WebSphere
traditional
Java API for RESTful Web Services (JAX-RS) - JSR 311
U
U
U
U
Java API for XML-Based Web Services (JAX-WS) - JSR
224
U
U
U
Java API for XML-Based Web Services (JAX-WS) Provided by application - JSR 224
U
U
U
Java Architecture for XML Binding (JAXB) - JSR 222
U
U
U
Web Services Metadata for the Java Platform - JSR 181
U
U
U
U
Java API for XML-based RPC (JAX-RPC) - JSR 101
U
Java API for XML-based RPC (JAX-RPC) - Provided by U
application - JSR 101
Java API for WSDL (JWSDL)
U
U
SOAP with Attachments API for Java (SAAJ) - JSR 67 - U
also referred to as Java APIs for XML Messaging
U
U
U
U
U
U
U
Java API for XML Registries (JAXR) - JSR 93
U
Web Services Notification (WS-Notification)
U
Web Services Atomic Transaction (WS-AT)
U
Web Services Business Activity (WS-BA)
U
Table 28. Java technologies in WebSphere Application Server platforms
Web application technologies
Bluemix
Liberty Core
Liberty
WebSphere
traditional
Java API for JSON Processing (JSON-P) - JSR 353
U
U
U
U
Java Servlet - JSR 315
U
U
U
U
JavaServer Faces (JSF) - JSR 314
U
U
U
U
JavaServer Pages/Expression Language (JSP/EL) - JSR
245
U
U
U
U
Standard Tag Library for JavaServer Pages (JSTL) - JSR U
52
U
U
U
© Copyright IBM Corp. 2009, 2016
65
Table 28. Java technologies in WebSphere Application Server platforms (continued)
Web application technologies
Bluemix
Liberty Core
Liberty
WebSphere
traditional
Java API for WebSocket - JSR 356
U
U
U
U
Liberty Core
Liberty
WebSphere
traditional
U
U
Table 28. Java technologies in WebSphere Application Server platforms
Enterprise application technologies
Bluemix
Batch Applications for the Java Platform - JSR 352
U
Concurrency Utilities for Java EE 1.0 - JSR 236
U
U
U
U
Contexts and Dependency Injection for Java (Web
Beans) - JSR 299
U
U
U
U
Dependency Injection for Java - JSR 330
U
U
U
U
Bean Validation - JSR 303
U
U
U
U
U
U
U
U
U
U
Enterprise JavaBeans (EJB) 2.x and 1.x - JSR 318
Enterprise JavaBeans (EJB) Lite subset - JSR 318
U
U
Remote Enterprise JavaBeans (EJB) - JSR 318
Enterprise JavaBeans (EJB) Timers - JSR 318
U
U
U
Message-Driven Beans (MDB) - JSR 318
U
U
U
Interceptors - JSR 318
U
U
U
Java Connector Architecture (JCA) - JSR 322
U
U
U
Java Persistence API (JPA) - JSR 317 or 338
U
U
U
U
Common Annotations for the Java Platform - JSR 250
U
U
U
U
Java Message Service (JMS) API - JSR 914
U
U
U
Java Message Service (JMS) API - Provided by
application - JSR 914
U
U
U
U
Java Transaction API (JTA) - JSR 907
U
U
U
U
JavaMail - JSR 919
U
U
U
U
JavaMail - Provided by application - JSR 919
U
U
U
U
U
Table 28. Java technologies in WebSphere Application Server platforms
Management and security technologies
Bluemix
Liberty Core
Liberty
WebSphere
traditional
Java Authentication Service Provider Interface for
Containers (JASPIC) - JSR 196
U
U
U
U
Java Authorization Contract for Containers (JACC) JSR 115
U
U
U
U
Java EE Application Deployment - JSR 88
J2EE Management - JSR 77
U
U
U
U
Table 28. Java technologies in WebSphere Application Server platforms
Java EE-related specifications in Java SE
Bluemix
Liberty Core
Liberty
WebSphere
traditional
Java API for XML Processing (JAXP) - JSR 206
U
U
U
U
Java Database Connectivity (JDBC) - JSR 221
U
U
U
U
Java Management Extensions (JMX) - JSR 255
U
U
U
U
66
Application Migration Tools
Table 28. Java technologies in WebSphere Application Server platforms (continued)
Java EE-related specifications in Java SE
Bluemix
Liberty Core
Liberty
WebSphere
traditional
JavaBeans Activation Framework (JAF) - JSR 925
U
U
U
U
Streaming API for XML (StAX) - JSR 173
U
U
U
U
Table 28. Java technologies in WebSphere Application Server platforms
Blueprint-related technologies
Bluemix
Liberty Core
Liberty
WebSphere
traditional
Blueprint Container
U
U
U
U
Blueprint transactions
U
U
U
U
Blueprint JPA
U
U
U
U
Blueprint security
U
U
U
U
Blueprint resource references
U
U
U
U
Table 28. Java technologies in WebSphere Application Server platforms
Web-related technologies in OSGi bundles
Bluemix
Liberty Core
Liberty
WebSphere
traditional
Web Application Bundles
U
U
U
U
Java Naming and Directory Interface (JNDI)
U
U
U
U
JavaServer Pages (JSP)
U
U
U
U
Standard Tag Library for JavaServer Pages (JSTL)
U
U
U
U
JavaServer Faces (JSF)
U
U
U
U
Java API for RESTful Web Services (JAX-RS)
U
U
U
U
Liberty Core
Liberty
WebSphere
traditional
Table 28. Java technologies in WebSphere Application Server platforms
Other enterprise technologies
Bluemix
EJB Bundles
U
Remote Service Admin
U
Repository Service
U
SCA Configuration Type Specification
Service Component Architecture (SCA) - IBM APIs
Service Component Architecture (SCA)
Service Component Architecture (SCA) - Oasis
provided by application
U
U
U
U
U
U
U
U
U
U
U
U
U
U
Service Component Architecture (SCA) - Oasis
Service Component Architecture (SCA) - OSOA
provided by application
Service Component Architecture (SCA) - OSOA
Service Component Architecture (SCA) - Tuscany
provided by application
Service Component Architecture (SCA) - Tuscany
Session Initiation Protocol (SIP)
U
Appendix C. Liberty migration rules
67
Rules for migrating applications to Liberty
The WebSphere Application Server traditional to Liberty migration rules identify application issues that
require changing when you move an application from Websphere Application Server traditional to
Liberty, Liberty Core, or Liberty for Java on IBM Bluemix or Liberty on third-party cloud platforms.
Table 29. Liberty migration rules
WebSphere Application Server traditional to Liberty rules
The tool scans applications for the following issues when migrating from WebSphere Application Server traditional
to all Liberty editions.
v Behavior change on lookups for Enterprise JavaBeans
v Behavior difference for web service host name validation
v CDI OpenWebBeans APIs are unavailable
v com.tivoli third-party APIs are unavailable on Liberty
v CommonJ Timer and Work Manager APIs are unavailable on Liberty
v Do not use the WSSecurityHelper getLTPACookieFromSSOToken method
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 org.apache third-party APIs are unavailable on Liberty
v org.apache.aries third-party APIs are unavailable on Liberty
v org.codehaus.jackson third-party APIs are unavailable on Liberty
v org.slf4j third-party APIs are unavailable on Liberty
v OSGi bundles might need explicit package imports
v Precompiled JSP classes must be removed
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 SOAP over Java Message Serivce (JMS) is unavailable
v Some org.apache.aries.blueprint third-party APIs are unavailable on Liberty
v Some third-party APIs are unavailable on Liberty
v Some WebSphere APIs are unavailable on Liberty
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 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
68
Application Migration Tools
Table 29. Liberty migration rules (continued)
WebSphere Application Server traditional to Liberty rules
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 was superseded by a newer implementation
v The WebSphere Startup Beans Service API was superseded by a newer implementation
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 User-defined EJB binding locations are ignored in Liberty
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
Table 29. Liberty migration rules
Java Technology Support for Liberty
The following rules are relevant when migrating applications to all editions of WebSphere Application Server
Liberty.
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 EE Application Deployment API is unavailable
v Java Portlet is unsupported
v JavaServer Faces (JSF) 1.1/1.2 compatibility
v Spring applications might fail to run from a non-expanded WAR file
v Stub classes must be included when using remote Enterprise JavaBeans (EJB) 2.x
v The getRealPath method returns null from a non-expanded WAR file
v Transaction propagation is not supported for Enterprise JavaBeans (EJB) remote interfaces
v Web Services Notification (WS-Notification) is unavailable
Appendix C. Liberty migration rules
69
Table 29. Liberty migration rules
Java Technology Support for 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 Session Initiation Protocol (SIP) Servlet API is unavailable
v Timer service for Enterprise JavaBeans (EJB) is unavailable
v Web Services Metadata for the Java Platform is unavailable
Table 30. WebSphere traditional to Liberty Java EE 6 differences
WebSphere traditional to Liberty Java EE 6 differences
This category contains rules that help analyze Java EE 6 differences between WebSphere Application Server
traditional and Liberty.
v The use of system provided Apache OpenJPA APIs requires configuration
v The use of system provided Apache Wink APIs requires configuration
70
Application Migration Tools
Appendix D. Java EE version migration
The majority of the rules in this section are related to moving from Java EE 6 to Java EE 7. The migration
rules represent behavior changes that were introduced in Java EE 7. Most of the changes in JAX-RS, CDI,
and JPA are because of underlying implementation changes. Migrating JAX-RS and JPA is optional
because the Java EE 6 implementations can run with the rest of the Java EE 7 profile.
The Java EE 6 rules contain behavior changes that were introduced in Java EE 6 for Liberty and
traditional WebSphere. There are also rules for traditional WebSphere that describe configuration that is
required to remain at the Java EE 6 level of JAX-RS or JPA.
Java EE 6 behavior differences
Java EE 6 might introduce some behavior differences in your application because of implementation
changes and specification clarifications.
Table 31. Servlet 3.0
Rule Name
Quick Fix
Action Taken
Do not use the HttpSession
invalidate method for
programmatic security logout in
Servlet 3.0
No
Do not use the HttpSession invalidate method for programmatic
security logout. Instead use the HttpServletRequest logout method
which was introduced in Java EE 6 as part of the Servlet 3.0
specification.
In Liberty and WebSphere Application Server traditional V9.0, you can use JAX-RS 1.1 or JPA 2.0 instead
of the updated versions of these technologies that were implemented in Java EE 7. If you do not run the
Java EE 7 migration rules for either JAX-RS or JPA technologies, the Java EE 6 rules remind you to
configure the server to use the Java EE 6 implementation.
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 Liberty, you are not required to
move to the next Java EE level and can continue to use the existing Java EE 6 features. In WebSphere
Application Server traditional V9.0, only the JAX-RS and JPA technologies can remain at the Java EE 6
level, and you must explicitly configure them on the server. All other technologies must be migrated to
the Java EE 7 level.
© Copyright IBM Corp. 2009, 2016
71
Table 32. WebSphere Java EE 7 differences
CDI 1.2
This category contains rules that help migrate from CDI 1.0 to CDI 1.2.
v An interceptor for lifecycle callbacks may only declare interceptor binding types that are defined as
@Target(TYPE)
v CDI recognizes implicit bean archives
v CDI scans for implicit beans when there is no beans.xml file
v Check for a behavior change in the InjectionPoint getAnnotated method
v Check for a valid schema in beans.xml
v Check for the enablement of interceptors, decorators and alternatives in other JAR files
v Classes that use both the Specializes and Alternative annotations are not injected into other modules
v Do not use the OpenWebBeans schema for beans.xml
v Producer fields on session beans must be static
v The openwebbeans.properties file is not used
v Transient fields in session-scoped beans cannot fail over successfully
Table 32. WebSphere Java EE 7 differences
EL 3.0
This category contains rules that help migrate to Expression Language 3.0.
v Behavior change in coerceToType method with null parameter
Table 32. WebSphere Java EE 7 differences
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 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.atom package is not available
v The org.apache.wink.common.model.multipart package is not available
v Use the isReadable and isWriteable methods to check the media type
Table 32. WebSphere Java EE 7 differences
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
72
Application Migration Tools
Table 32. WebSphere Java EE 7 differences
Servlet 3.1
This category contains rules that help migrate from Servlet 3.0 to Servlet 3.1.
v Check for a behavior change in the processing of the absolute-ordering element
v Check for a behavior change on asynchronous servlets
v Check for a behavior change on the getServerInfo method
v Check for a behavior change on the sendRedirect method
v Check for a behavior change on the ServletContextListener interface
v Check for a behavior change on the setComment method
v Check for a behavior change regarding duplicate elements in web descriptors
v Check for a behavior change with resource reference injection target merging
v Check for a behavior change with URL pattern mapping
Table 32. 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 Do not use OpenJPA strings for query hints or properties
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 Mapping files are not processed during OpenJPA to EclipseLink migration
v OpenJPA and WebSphere JPA configuration properties must be migrated
v OrderColumn annotations are not supported on Set attributes
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 the mapping file
v The openjpa.LockManager configuration property must be migrated
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
Appendix D. Java EE version migration
73
74
Application Migration Tools
Appendix E. 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 Liberty or
WebSphere Application Server traditional V8.5.5.9 and later, you can choose Java SE 6, 7, or 8 as your
target. For WebSphere traditional V9.0, you must migrate to Java SE 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 33. J2SE 5.0 compatibility impacts
Rule Name
Quick Fix Action Taken
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.
© Copyright IBM Corp. 2009, 2016
75
Table 33. J2SE 5.0 compatibility impacts (continued)
Rule Name
Quick Fix Action Taken
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.
76
Application Migration Tools
Table 33. J2SE 5.0 compatibility impacts (continued)
Rule Name
Quick Fix Action Taken
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 34. Java SE 6 compatibility impacts
Rule Name
Quick Fix Action Taken
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.
Java SE 7 compatibility impacts
Table 35. Java SE 7 compatibility impacts
Rule Name
Quick Fix Action Taken
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.
Appendix E. Java SE version migration
77
Table 35. Java SE 7 compatibility impacts (continued)
Rule Name
Quick Fix Action Taken
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.
Check for a behavior change on
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.
Check for a behavior change on
MouseEvent getButton method
No
This rule flags instances of the java.awt.event.MouseEvent
getButton() method as it has a new behavior.
Check for a behavior change on
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.
78
Application Migration Tools
Java SE 8 compatibility impacts
Java 8 is supported on Liberty and WebSphere Application Server traditional V8.5.5.9 and later.
Table 36. Java SE 8 compatibility impacts
Rule Name
Quick Fix Action Taken
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.
Appendix E. Java SE version migration
79
Table 36. Java SE 8 compatibility impacts (continued)
Rule Name
Quick Fix Action Taken
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 a Liberty server using an Oracle
Java Runtime, do not run the quick fixes for these rules.
Table 37. Oracle to IBM compatibility impacts
Rule Name
Quick Fix Action Taken
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.
80
Application Migration Tools
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 38. Sun internal APIs
Rule Name
Quick Fix Action Taken
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.
Appendix E. Java SE version migration
81
82
Application Migration Tools
Appendix F. 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, rules common to all application servers,
rules common to all competitive application servers, 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 E, “Java SE version migration,” on page 75. 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 100. The common
rules for all competitive migration rule sets are described in “Common rules for competitive migration
rule sets” on page 99. The common rules for all application servers are described in “Common rules for
all application servers” on page 99.
WebLogic Server Java code review rules
Under the Java Code Review set of rules, the WebLogic to WebSphere code migration category contains
multiple rules. To learn how to get more information about a rule, see “Displaying detailed help” on
page 30.
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.
© Copyright IBM Corp. 2009, 2016
83
Rule Name
Quick Fix
Action Taken
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.
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.
Do not use the WebLogic
MessageProducer API
No
This rule detects the use of the
weblogic.jms.extensions.WLMessageProducer API.
Do not use the WebLogic
ServletAuthentication invalidateAll
method
No
This rule detects the use of the
weblogic.servlet.security.ServletAuthentication invalidateAll
method.
Do not use the WebLogic
No
TransactionHelper getUserTransaction
method
This rule detects the use of the
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.
84
Application Migration Tools
Rule Name
Quick Fix
Do not use weblogic.apache packages Yes
Action Taken
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.
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
This rule detects the use of the
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 F. Third-party application server migration rules and quick fixes
85
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
This rule detects the use of the
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")
86
Application Migration Tools
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 WebLogic to WebSphere JSP Migration category has rules specific to WebLogic that are described in
the following table. To learn how to get more information about a rule, see “Displaying detailed help” on
page 30.
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.
Appendix F. Third-party application server migration rules and quick fixes
87
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.
Use WebSphere bindings to
define EJB local reference JNDI
names
Yes
Use WebSphere bindings to
define EJB reference names
Yes
This rule detects <ejb-local-ref> tags in weblogic-ejb-jar.xml files
for EJB definitions.
The quick fix migrates the value found to the EJB bindings file.
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.
Use WebSphere bindings to
Yes
define message-driven bean JNDI
names
This rule detects <destination-jndi-name> for message-driven beans.
Use WebSphere bindings to
define resource environment
reference JNDI names
Yes
This rule detects <resource-env-description> elements in
weblogic.xml or weblogic-ejb-jar.xml files.
Use WebSphere bindings to
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
weblogic-ejb-jar.xml files.
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
weblogic-ejb-jar.xml files.
The quick fix defines the timeout value to the EJB extensions file.
Use WebSphere extensions to
Yes
define virtual directory mappings
This rule detects WebLogic Server virtual directory mapping
configuration and migrates entries to use WebSphere file serving.
Use WebSphere extensions to
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 WebSphere Application Server traditional 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 WebSphere Application Server traditional rule detects query
language elements, weblogic-ql, in weblogic-cmp-rdbms-jar.xml
files for manual migration.
Do not use WebLogic-specific
JNDI name values or the t3
protocol
This WebSphere Application Server traditional rule detects
non-portable WebLogic Server JNDI lookup values or URLs with
the t3 or t3s protocol.
88
Application Migration Tools
Yes
Rule Name
Quick Fix
Action Taken
Do not use WebLogic web
services deployment descriptor
Yes
This WebSphere Application Server traditional 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.
Use WebSphere extensions to
define CMP mappings
Yes
This WebSphere Application Server traditional 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.
Use WebSphere extensions to
define concurrency strategy
Yes
This rule detects the <concurrency-strategy> element in
weblogic-ejb-jar.xml files.
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.
Appendix F. Third-party application server migration rules and quick fixes
89
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
look for any unmigrated elements at the end of the application
migration.
Do not use weblogicdiagnostics.xml file
No
This rule flags the weblogic-diagnostics.xml file so that you can
look for any unmigrated elements at the end of the application
migration.
Do not use weblogic-ejb-jar.xml
file
No
This rule flags the weblogic-ejb-jar.xml file so that you can look
for any unmigrated elements at the end of the application
migration.
Do not use weblogic-ra.xml file
No
This rule flags the weblogic-ra.xml file so that you can look for any
unmigrated elements at the end of the application migration.
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
Do not use WebLogic-specific
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.
90
Application Migration Tools
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, rules common to all application servers, rules
common to all competitive application servers, 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 E, “Java SE version migration,” on page 75. 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 100. The
common rules for all competitive migration rule sets are described in “Common rules for competitive
migration rule sets” on page 99. The common rules for all application servers are described in “Common
rules for all application servers” on page 99.
JBoss Java code review rules
Under the Java code review set of rules, the JBoss to WebSphere code migration category contains
multiple rules. To learn how to get more information about a rule, see “Displaying detailed help” on
page 30.
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.
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 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.
Appendix F. Third-party application server migration rules and quick fixes
91
Rule Name
Quick Fix
Action Taken
Do not use JBoss-specific JNDI
property values
Yes
This WebSphere Application Server traditional 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 WebSphere Application Server traditional rule detects JBoss
JAX-RPC and JAX-WS timeout constants to be migrated to IBM
web service timeout constants.
JBoss Application 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 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.
Use WebSphere bindings to
define EJB JNDI names
Yes
This rule detects the <jndi-name> tag in jboss.xml files for EJB
definitions.
The quick fix migrates the value found to the EJB bindings file.
Use WebSphere bindings to
define EJB local reference JNDI
names
Yes
Use WebSphere bindings to
define EJB reference names
Yes
This rule detects <ejb-local-ref> tags in jboss.xml files for EJB
definitions.
The quick fix migrates the value found to the EJB bindings file.
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.
Use WebSphere bindings to
Yes
define message-driven Bean JNDI
names
92
Application Migration Tools
This rule detects <destination-jndi-name> for message-driven beans.
The quick fix sets the destination JNDI name in the EJB bindings
file.
Rule Name
Quick Fix
Action Taken
Use WebSphere bindings to
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.
Use WebSphere bindings to
define resource reference names
Yes
This rule detects <res-ref-name> elements in jboss-web.xml or
jboss.xml files.
The quick fix adds JNDI name of the resource reference to the EJB
bindings file.
Use WebSphere extensions to
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 WebSphere Application Server traditional 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.
Use WebSphere extensions to
define CMP mappings
Yes
This WebSphere Application Server traditional 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
unmigrated elements at the end of the application migration.
Do not use jboss-app.xml file
No
This rule flags the jboss-app file so that you can look for any
unmigrated elements at the end of the application migration.
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
any unmigrated elements at the end of the application migration.
Do not use jboss-web.xml file
This rule flags the jboss-web.xml file so that you can look for any
unmigrated elements at the end of the application migration.
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.
Appendix F. Third-party application server migration rules and quick fixes
93
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, rules common to all application servers,
rules common to all competitive application servers, 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 E, “Java SE version migration,” on page 75. 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 100. The
common rules for all competitive migration rule sets are described in “Common rules for competitive
migration rule sets” on page 99. The common rules for all application servers are described in “Common
rules for all application servers” on page 99.
Oracle Application Server Java code review rules
Under the Java code review set of rules, the Oracle to WebSphere code migration category contains
multiple rules. To learn how to get more information about a rule, see “Displaying detailed help” on
page 30.
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.
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 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.
94
Application Migration Tools
Rule Name
Quick Fix
Action Taken
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.
Oracle Application Server JSP code review rules
The Oracle to WebSphere JSP Migration category has rules specific to Oracle that are described in the
following table. To learn how to get more information about a rule, see “Displaying detailed help” on
page 30.
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
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 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.
Use WebSphere bindings to
define EJB reference names
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.
Use WebSphere bindings to
Yes
define message-driven bean JNDI
names
This rule detects <destination-jndi-name> for message-driven beans.
Use WebSphere bindings to
define resource reference names
This rule detects resource references in the orion-web.xml or
orion-ejb-jar.xm files.
Yes
The quick fix sets the destination JNDI name in the EJB bindings
file.
The quick fix adds the JNDI name of the resource reference to the
EJB bindings file.
Appendix F. Third-party application server migration rules and quick fixes
95
Rule Name
Quick Fix
Action Taken
Use WebSphere configuration to
control class loader order
No
This rule detects the presence of the search-local-classes-first setting
used to control class loading order.
Do not use MDB 2.0 listener ports No
This WebSphere Application Server traditional rule detects the
message-driven bean (MDB) 2.0 listener ports in the ejb-jar.xml
file.
Do not use Oracle web services
deployment descriptor
This WebSphere Application Server traditional rule flags
oracle-webservices.xml J2EE deployment descriptor files.
Yes
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.
Use WebSphere extensions to
define CMP mappings
No
This WebSphere Application Server traditional rule detects
enterprise bean to relational database mappings that are used for
container-managed persistence (CMP).
Use WebSphere extensions to
define concurrency strategy
Yes
This WebSphere Application Server traditional 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
any unmigrated elements at the end of the application migration.
Do not use global-webapplication.xml file
No
This rule flags the global-web-application.xml file so that you can
look for any unmigrated elements at the end of the application
migration.
Do not use jazn-data.xml file
No
This rule flags the jazn-data.xml file so that you can look for any
unmigrated elements at the end of the application migration.
Do not use oc4j-connectors.xml
file
No
This rule flags the oc4j-connectors.xml file so that you can look for
any unmigrated elements at the end of the application migration.
Do not use oc4j-ra.xml file
No
This rule flags the oc4j-ra.xml file so that you can look for any
unmigrated elements at the end of the application migration.
Do not use oraclewebservices.xml file
No
This rule flags the oracle-webservices.xml file so that you can look
for any unmigrated elements at the end of the application
migration.
Do not use orion-application.xml
file
No
This rule flags the orion-application.xml file so that you can look
for any unmigrated elements at the end of the application
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
any unmigrated elements at the end of the application migration.
96
Application Migration Tools
Rule Name
Quick Fix
Action Taken
Do not use orion-web.xml file
No
This rule flags the orion-web.xml file so that you can look for any
unmigrated elements at the end of the application migration.
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, rules common to all application servers,
rules common to all competitive application servers, 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 E, “Java SE version migration,” on page 75. 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 100. The common rules for all
competitive migration rule sets are described in “Common rules for competitive migration rule sets” on
page 99. The common rules for all application servers are described in “Common rules for all application
servers” on page 99.
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. To learn how to get more information about a rule, see “Displaying detailed
help” on page 30.
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 "/").
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 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.
Appendix F. Third-party application server migration rules and quick fixes
97
Rule Name
Quick Fix
Action Taken
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.
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.
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.
Use Java EE deployment
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.
Use Java EE deployment
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.
Use Java EE deployment
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.
Use Java EE deployment
Yes
descriptors to define environment
references
This rule migrates Context Environment information from the
META-INF/context.xml file to the web.xml file.
Use Java EE deployment
descriptors to define missing
security roles
This rule flags <auth-constraint> elements in web.xml that are
missing associated security-role elements.
98
Application Migration Tools
Yes
Common rules for all application servers
These rules are applicable to all application servers. To learn how to get more information about a rule,
see “Displaying detailed help” on page 30.
Table 39. All migrations
Rule Name
Quick Fix
Action Taken
Check for compatibility when
using system modules
No
Using a system module compiled for a specific platform will not be
compatible when moving to a different operating system.
Configure the correct target
runtime for your application
No
When migrating to WebSphere Application Server traditional or
Liberty, or between versions of WebSphere, the target runtime
should be configured to reference the target application server
runtime.
Do not start unmanaged threads
within the web or EJB container
No
Unmanaged threads can adversely affect application server
functions.
Common rules for competitive migration rule sets
This Java code review rule is available to competitive migration rule sets. To learn how to get more
information about a rule, see “Displaying detailed help” on page 30.
Rule Name
Quick Fix
Action Taken
Define separate interfaces for
local and remote Enterprise
JavaBeans (EJB)
No
An interface cannot be local and remote at the same time.
These JSP rules are available to competitive migration rule sets.
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.
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.
This TLD rule is selected with the competitive migration rule sets and is found under the File Review
category.
Appendix F. Third-party application server migration rules and quick fixes
99
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.
These XML file review rules are available to competitive migration rule sets.
Rule Name
Quick Fix
Action Taken
Check Ehcache configuration
No
Using Ehcache can result in stability issues if the cache is not
explicitly sized.
Define separate interfaces for
local and remote Enterprise
JavaBeans (EJB)
No
An interface cannot be local and remote at the same time.
Framework migration
Under the File Review, Java Code Review and 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 rules provide information to help you
verify that the framework is compatible with WebSphere Application Server.
Table 40. Framework migration
Rule Name
Quick Fix Action Taken
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 flags hibernate.cfg.xml files, hibernate.properties
files, and references to the org.hibernate.cfg.Configuration
class so that you can verify that Hibernate is configured
properly for 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.
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.
100
Application Migration Tools
Rule Name
Quick Fix Action Taken
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.
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.
Appendix F. Third-party application server migration rules and quick fixes
101
Table 41. Framework migration
Rule Name
Quick Fix Action Taken
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.
Do not use the Hibernate Query
methods to set parameters
No
This rule flags org.hibernate.Query set-parameter methods.
Use the javax.persistence.Query setParameter method instead.
Do not use the Hibernate Query
setParameterList or setParameters
methods
No
This rule flags the org.hibernate.Query setParameterList and
setParameters methods. Use the javax.persistence.Query
setParameter method instead.
Do not use the Hibernate Query
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.
Do not use the Hibernate Session
createCriteria method
No
This rule flags the org.hibernate.Session createCriteria
method. Use the javax.persistence.EntityManager
getCriteriaBuilder method followed by a call to the
javax.persistence.criteria.CriteriaBuilder createQuery method.
Do not use the Hibernate Session
createQuery method
No
This rule flags the org.hibernate.Session createQuery method.
Use the javax.persistence.EntityManager createQuery method
instead.
Do not use the Hibernate Session
createSQLQuery method
No
This rule flags the org.hibernate.Session createSQLQuery
method. Use the javax.persistence.EntityManager
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.
Do not use the Hibernate SessionFactory
isClosed method
No
This rule flags the org.hibernate.SessionFactory isClosed
method. Use the javax.persistence.EntityManagerFactory
isOpen method instead.
Do not use the Hibernate SessionFactory
openSession method
No
This rule flags the org.hibernate.SessionFactory openSession
method. Use the javax.persistence.EntityManagerFactory
createEntityManger method instead.
Do not use the Hibernate Session
getNamedQuery method
No
This rule flags the org.hibernate.Session getNamedQuery
method. Use the javax.persistence.EntityManager
createNamedQuery method instead.
102
Application Migration Tools
Table 41. Framework migration (continued)
Rule Name
Quick Fix Action Taken
Do not use the Hibernate Session
getSessionFactory method
No
This rule flags the org.hibernate.Session getSessionFactory
method. Use the javax.persistence.EntityManager
getEntityManagerFactory method instead.
Do not use the Hibernate Session
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.
Do not use the Hibernate Session
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.
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
Quick Fix Action Taken
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.
Appendix F. Third-party application server migration rules and quick fixes
103
104
Application Migration Tools
Appendix G. 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 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 WebSphere Application Server
Liberty migratedConfig/server.xml file.
Table 42. Configuration elements that are migrated from the conf/server.xml file
Tomcat configuration element
Liberty configuration
element
Migrated attributes
Tomcat attribute = Liberty 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
© Copyright IBM Corp. 2009, 2016
105
Table 42. Configuration elements that are migrated from the conf/server.xml file (continued)
Tomcat configuration element
Liberty configuration
element
Migrated attributes
Tomcat attribute = Liberty attribute
Service/Connector with scheme attribute https and httpEndpoint
protocol attribute default or 'HTTP/1.1' or
'org.apache.coyote.http11.Http11NioProtocol' or
'org.apache.coyote.http11.Http11Protocol'
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
securityUtility command)
Service/Engine/Host
virtualHost
name = id
Alias = hostAlias
106
Application Migration Tools
Table 42. Configuration elements that are migrated from the conf/server.xml file (continued)
Tomcat configuration element
Liberty configuration
element
Migrated attributes
Tomcat attribute = Liberty attribute
Resource with driverClassName
'org.apache.derby.jdbc.EmbeddedDriver'
dataSource
name = jndiName
username = containerAuthData/
@user
password = containerAuthData/
@password (xor encoded using
the securityUtility command)
url = properties.derby.embedded/
@createDatabase, @databaseName
defaultTransactionIsolation =
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
maxIdle = connectionManager/
@minPoolSize
maxWait = connectionManager/
@connectionTimeout
Resource with driverClassName
'com.ibm.db2.jcc.DB2Driver'
dataSource
name = jndiName
username = containerAuthData/
@user
password = containerAuthData/
@password (xor encoded using
the securityUtility command)
url = properties.db2.jcc/
@databaseName, @serverName,
@portNumber
defaultTransactionIsolation =
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
maxIdle = connectionManager/
@minPoolSize
maxWait = connectionManager/
@connectionTimeout
Appendix G. Migrated Apache Tomcat configuration elements
107
Table 42. Configuration elements that are migrated from the conf/server.xml file (continued)
Tomcat configuration element
Liberty configuration
element
Migrated attributes
Tomcat attribute = Liberty attribute
Resource with driverClassName
'oracle.jdbc.driver.OracleDriver' or
'oracle.jdbc.OracleDriver'
dataSource
name = jndiName
username = containerAuthData/
@user
password = containerAuthData/
@password (xor encoded using
the securityUtility command)
url = properties.oracle/@URL,
@driverType
defaultTransactionIsolation =
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
maxIdle = connectionManager/
@minPoolSize
maxWait = connectionManager/
@connectionTimeout
Resource with driverClassName
'com.sybase.jdbc3.jdbc.SybDriver' or
'com.sybase.jdbc4.jdbc.SybDriver'
dataSource
name = jndiName
username = containerAuthData/
@user
password = containerAuthData/
@password (xor encoded using
the securityUtility command)
url = properties.sybase/
@databaseName, @serverName,
@portNumber
defaultTransactionIsolation =
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
maxIdle = connectionManager/
@minPoolSize
maxWait = connectionManager/
@connectionTimeout
108
Application Migration Tools
Table 42. Configuration elements that are migrated from the conf/server.xml file (continued)
Tomcat configuration element
Liberty configuration
element
Migrated attributes
Tomcat attribute = Liberty attribute
Resource with driverClassName
'com.ddtek.jdbc.sqlserver.SQLServerDriver'
dataSource
name = jndiName
username = containerAuthData/
@user
password = containerAuthData/
@password (xor encoded using
the securityUtility command)
url =
properties.datadirect.sqlserver/
@serverName, @portNumber,
@databaseName
defaultTransactionIsolation =
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
maxIdle = connectionManager/
@minPoolSize
maxWait = connectionManager/
@connectionTimeout
Resource with driverClassName
'com.microsoft.sqlserver.jdbc.SQLServerDriver'
dataSource
name = jndiName
username = containerAuthData/
@user
password = containerAuthData/
@password (xor encoded using
the securityUtility command)
url =
properties.microsoft.sqlserver/
@URL
defaultTransactionIsolation =
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
maxIdle = connectionManager/
@minPoolSize
maxWait = connectionManager/
@connectionTimeout
Appendix G. Migrated Apache Tomcat configuration elements
109
Table 42. Configuration elements that are migrated from the conf/server.xml file (continued)
Tomcat configuration element
Liberty configuration
element
Migrated attributes
Tomcat attribute = Liberty attribute
Resource with driverClassName
'com.ddtek.jdbc.sqlserver.SQLServerDriver'
dataSource
name = jndiName
username = containerAuthData/
@user
password = containerAuthData/
@password (xor encoded using
the securityUtility command)
url =
properties.datadirect.sqlserver/
@serverName, @portNumber,
@databaseName
defaultTransactionIsolation =
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
maxIdle = connectionManager/
@minPoolSize
maxWait = connectionManager/
@connectionTimeout
Resource with driverClassName
'com.mysql.jdbc.Driver'
dataSource
name = jndiName
username = containerAuthData/
@user
password = containerAuthData/
@password (xor encoded using
the securityUtility command)
url = properties/@URL
defaultTransactionIsolation =
isolationLevel
maxActive =
connectionManager/
@maxPoolSize
maxIdle = connectionManager/
@minPoolSize
maxWait = connectionManager/
@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
Resource with type
'org.apache.activemq.command.ActiveMQQueue'
jmsQueue
name = jndiName
id = jndiName
physicalName =
properties.wasJms/@topicName
110
Application Migration Tools
Table 42. Configuration elements that are migrated from the conf/server.xml file (continued)
Tomcat configuration element
Liberty configuration
element
Migrated attributes
Tomcat attribute = Liberty attribute
Resource with type
'com.ibm.mq.jms.MQConnectionFactory'
jmsConnectionFactory
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 =
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.MQTopicConnectionFactory'
jmsTopicConnectionFactory
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.MQTopic'
jmsTopic
name = jndiName
TOP or TOPIC =
properties.wmqJms/
@baseTopicName
Appendix G. Migrated Apache Tomcat configuration elements
111
Table 42. Configuration elements that are migrated from the conf/server.xml file (continued)
Tomcat configuration element
Liberty configuration
element
Migrated attributes
Tomcat attribute = Liberty attribute
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 WebSphere Application Server
Liberty migratedConfig/context.xml file.
Table 43. Configuration elements that are migrated from the conf/context.xml file
Tomcat configuration element
Liberty configuration
element
Migrated attributes
Tomcat attribute = Liberty attribute
Manager with className
'org.apache.catalina.session.StandardManager'
httpSession
maxActiveSessions =
maxInMemorySessionCount
maxInactiveInterval =
invalidationTimeout
sessionIdLength = idLength
processExpiresFrequency =
forceInvalidationMultiple
Resource with driverClassName
'org.apache.derby.jdbc.EmbeddedDriver'
dataSource
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with driverClassName
'com.ibm.db2.jcc.DB2Driver'
dataSource
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with driverClassName
'oracle.jdbc.driver.OracleDriver' or
'oracle.jdbc.OracleDriver'
dataSource
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with driverClassName
'com.sybase.jdbc3.jdbc.SybDriver' or
'com.sybase.jdbc4.jdbc.SybDriver'
dataSource
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type
jmsConnectionFactory
'org.apache.activemq.ActiveMQConnectionFactory'
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type
'org.apache.activemq.command.ActiveMQTopic'
jmsTopic
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type
'org.apache.activemq.command.ActiveMQQueue'
jmsQueue
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type
'com.ibm.mq.jms.MQConnectionFactory'
jmsConnectionFactory
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type
'com.ibm.mq.jms.MQQueueConnectionFactory'
jmsQueueConnectionFactory See the table about the
conf/server.xml file for details
on migrated attributes.
112
Application Migration Tools
Table 43. Configuration elements that are migrated from the conf/context.xml file (continued)
Tomcat configuration element
Liberty configuration
element
Migrated attributes
Tomcat attribute = Liberty attribute
Resource with type
'com.ibm.mq.jms.MQTopicConnectionFactory'
jmsTopicConnectionFactory
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type 'com.ibm.mq.jms.MQTopic'
jmsTopic
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type 'com.ibm.mq.jms.MQQueue'
jmsQueue
See the table about the
conf/server.xml file for 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 WebSphere Application Server
Liberty migratedConfig/web.xml file.
Table 44. Configuration elements migrated from the conf/web.xml file
Tomcat configuration element
Liberty configuration element Migrated elements
mime-mapping/extension and mime-mapping/mimetype
mimeTypes/type
The Liberty mimeTypes/type
value is set to
extension=mime-type.
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 WebSphere Application Server Liberty migratedConfig/[tomcat-usersfile]_users-and-roles.xml file, where tomcat-users-file is the name of the source Tomcat file.
Table 45. Configuration elements that are migrated from tomcat-users elements
Tomcat configuration element
Liberty configuration element Migrated attributes
Tomcat attribute = Liberty
attribute
tomcat-users/role
basicRegistry/group
rolename = name
tomcat-users/user
basicRegistry/user
username = name
password = password (hash
encoded using the
securityUtility command)
roles = group/
member[@name]
A group member is created for
each role.
Appendix G. Migrated Apache Tomcat configuration elements
113
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
WebSphere Application Server Liberty migratedConfig/<application-name>/application-configcontext.xml file.
Table 46. Configuration elements that are migrated from the application META-INF/context.xml file
Tomcat configuration element
Liberty configuration
element
Migrated attributes
Tomcat attribute = Liberty attribute
Resource with driverClassName
'org.apache.derby.jdbc.EmbeddedDriver'
dataSource
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with driverClassName
'com.ibm.db2.jcc.DB2Driver'
dataSource
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with driverClassName
'oracle.jdbc.driver.OracleDriver' or
'oracle.jdbc.OracleDriver'
dataSource
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with driverClassName
'com.sybase.jdbc3.jdbc.SybDriver' or
'com.sybase.jdbc4.jdbc.SybDriver'
dataSource
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type
jmsConnectionFactory
'org.apache.activemq.ActiveMQConnectionFactory'
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type
'org.apache.activemq.command.ActiveMQTopic'
jmsTopic
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type
'org.apache.activemq.command.ActiveMQQueue'
jmsQueue
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type
'com.ibm.mq.jms.MQConnectionFactory'
jmsConnectionFactory
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type
'com.ibm.mq.jms.MQQueueConnectionFactory'
jmsQueueConnectionFactory See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type
'com.ibm.mq.jms.MQTopicConnectionFactory'
jmsTopicConnectionFactory
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type 'com.ibm.mq.jms.MQTopic'
jmsTopic
See the table about the
conf/server.xml file for details
on migrated attributes.
Resource with type 'com.ibm.mq.jms.MQQueue'
jmsQueue
See the table about the
conf/server.xml file for details
on migrated attributes.
114
Application Migration Tools
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
WebSphere Application Server Liberty migratedConfig/<application-name>/application-config-web.xml
file.
Table 47. Configuration elements migrated from the application WEB-INF/web.xml file
Tomcat configuration element
Liberty configuration element Migrated attributes
Tomcat attribute = Liberty
attribute
web-app/security-constraint/auth-constraint
application/application-bnd/
security-role
role-name = name
Appendix G. Migrated Apache Tomcat configuration elements
115
116
Application Migration Tools
Copyright and trademarks
© Copyright IBM Corporation 2009, 2016.
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.
© Copyright IBM Corp. 2009, 2016
117
118
Application Migration Tools
IBM®
Printed in USA