Professional Documents
Culture Documents
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.
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.
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
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 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)
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
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/tools-
WebSphere_Configuration_Migration_Tool.
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
Chapter 1. Overview 3
v WebSphere Application Server traditional V9.0
v WebSphere Application Server Liberty
v WebSphere Application Server Liberty Core
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 WebSphere Migration Knowledge Collection: Planning and Resources 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.
All of the functional enhancements this release were in the binary scanner. Check out the new capabilities
in the command line tool including:
v A redesigned application evaluation report that provides a summary per application
v A new shared libraries option in the Application Inventory Report to include external dependencies in
the application scan
v A new section in the Application Inventory Report on performance considerations
Support
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
2. In the configurations list, select Software Analyzer. Then, click New . The right side of the window
changes to show the basic configuration interface.
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.
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
v Other third-party servers
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.
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.
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.
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.
v Quick Fix - The light bulb overlay on the result list icon ( ) indicates that this rule has a quick fix.
Selecting this option runs the conversion that modifies the affected Java code, XML file, JSP or manifest
file, allowing it to run in WebSphere Application Server. The quick fix might change the code directly
or it might present the steps needed to complete the fix.
v Quick Fix Preview - This option is available for the rules that support showing a side-by-side
comparison of the original code and the code after the quick fix is applied. This option allows you to
see the changes before they are made.
Some quick fixes modify more than one file. When you select Quick Fix Preview for a fix affecting
multiple files, the files are shown in the Structure Compare portion of the Compare view. Double-click
each file to view the differences.
v Ignore Result - This option removes the rule from the list without making a code change. For Java
and XML files, a comment annotation is added to the file so that the rule is not triggered on future
analysis runs.
v Quick Fix All - This option resolves all issues identified for a given rule.
v Quick Fix All Category - This option runs all quick fixes identified for the category to which the rule
belongs. A rule must have Quick Fix All enabled for the Quick Fix All Category option to run its
quick fix. For example, if you choose this option on a Java rule, the quick fixes for all Java rules that
have the Quick Fix All option are run.
Rule Severity
The rule severity helps identify the impact of an issue on your application migration.
On Windows:
v Press F1
On Linux:
v Press Shift-F1
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.
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 selected Liberty server now contains the updated configuration. The server.xml file contains an
include of the server-updates-for-application.xml file.
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:
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.
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.
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-updates-
for-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.
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.
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.
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-and-
roles.xml.
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.
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.
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:
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.
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 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.
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:
The Quick Fix erroneously duplicates the xmlns attribute and changes the value of the xmlns:ejb attribute
as shown in the following example.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
WebSphere Application Server conversion rules are included in the following 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.
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.
The quick fix changes the code to use the Oracle 11g helper
after confirming that the runtime configuration was changed.
Note: JSP pages written in XML syntax (JSP documents) are not supported.
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.
File review
The file review rules analyzes issues in files other than Java, XML, JSP in your application.
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
Table 19. Java deprecated features - Deprecated before V8.0 and removed in V8.0
Quick
Rule Name Fix Action Taken
Avoid using the deprecated Apache No This rule flags references to the org.apache.soap and
SOAP API com.ibm.soap packages.
Avoid using the deprecated Yes This rule flags the use of the deprecated Oracle data store helper
OracleDataStoreHelper class and field.
The quick fix changes the code to use the Oracle 11g helper after
confirming that the server runtime configuration was changed.
Table 22. Java deprecated features - Deprecated in V8.5 and removed in V9.0
Quick
Rule Name Fix Action Taken
Avoid using the deprecated Common No This rule flags APIS from the deprecated com.ibm.events
Event Infrastructure packages packages.
Avoid using the deprecated CEA No This rule flags use of the Communications Enabled Applications
system application commsvc.ear (CEA) REST interface provided by the deprecated CEA system
application commsvc.ear.
This section provides information on the technologies included in the the report and the rules in the
detailed analysis.
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.
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.
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.
This rule detects the use of these packages and flags them.
Do not use JAXP 1.1 package names in No Some of the implementation package names changed
string literals 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 The BigDecimal toString() method behaves differently than in
method explicitly when deriving a string earlier versions. J2SE 5.0 added toPlainString() to BigDecimal,
value 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() Yes The BigDecimal toString() method behaves differently than in
method instead of the toString() method earlier versions. J2SE 5.0 added toPlainString() to BigDecimal,
which behaves like the toString() method in earlier versions.
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.
These references are flagged so you can evaluate their usage and
migrate manually.
Do not use JNDI name lookup to No This rule detects the string literal "java:comp/env/jmx/runtime"
reference the runtime MBean server 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 This rule detects JPA properties that start with kodo.* in java
no openJPA equivalent files but have no equivalent openJPA values.
Do not use non-mapping No This rule detects import and code references to classes where the
weblogic.apache packages class package starts with weblogic.apache and the class does not
map to an open source Apache class.
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 changes the class to use the standard JPA object.
Do not use the WebLogic No This rule detects classes that implement the WebLogic
ApplicationLifecycleListener interface weblogic.application.ApplicationLifecycleListener interface. A
recommended migration alternative is to use the
javax.servlet.ServletContextListener interface.
Do not use the WebLogic domain for No This rule detects a string literal that starts with "com.bea" in Java
JMX object names 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 No This rule detects the use of the
MessageProducer API weblogic.jms.extensions.WLMessageProducer API.
Do not use the WebLogic No This rule detects the use of the
ServletAuthentication invalidateAll weblogic.servlet.security.ServletAuthentication invalidateAll
method method.
Do not use the WebLogic No This rule detects the use of the
TransactionHelper getUserTransaction weblogic.transaction.TransactionHelper getUserTransaction
method method.
Do not use UserTransaction interface No This rule detects references to ctx.lookup(’javax.transaction.
from CMT beans UserTransaction’) within container managed transaction
enterprise beans. References to the UserTransaction object are
not allowed from CMT beans.
These references are flagged so that you can remove this Java EE
violation.
The quick fix changes the code to use the Java objects.
Do not use WebLogic Yes This rule detects the NonCatalogLogger usage.
NonCatalogLogger object
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.
Do not use WebLogic RMI API calls Yes This rule detects the use of references to the proprietary
weblogic.rmi packages.
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 No This rule detects imported classes that begin with weblogic but
packages not including the weblogic.apache classes. The flagged
server-specific APIs must be migrated.
Do not use WebLogic-specific SSL Yes This rule detects instances of the string literal
protocols "com.certicom.net.ssl" and "weblogic.net" in Java files.
Do not use WebLogic startup or Yes This rule detects classes that implement the WebLogic Server
shutdown classes startup and shutdown interfaces.
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 No This rule detects all invocations of the
application servers 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 Yes This rule detects references to ctx.lookup("javax.transaction.
lookup name UserTransaction").
The quick fix adds any missing exceptions and removes any
additional exceptions. The interfaces are not changed.
Use OpenJPA property names instead Yes This rule detects the presence of known JPA properties with a
of Kodo-specific property names name starting with kodo.* in Java files.
when equivalent
The quick fix renames these properties to openjpa.*.
Use OpenJPA property values instead Yes This rule detects the JPA properties with kodo specific values in
of Kodo-specific property values Java files.
The quick fix adds the missing values to offer similar behavior
to WebLogic Server automated deployment.
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.
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 Yes This rule detects the <jndi-name> tag in weblogic-ejb-jar.xml files
define EJB JNDI names for EJB definitions.
The quick fix migrates the value found to the EJB bindings file.
Use WebSphere bindings to Yes This rule detects <ejb-local-ref> tags in weblogic-ejb-jar.xml files
define EJB local reference JNDI for EJB definitions.
names
The quick fix migrates the value found to the EJB bindings file.
Use WebSphere bindings to Yes This rule detects <ejb-ref-name> in weblogic.xml or
define EJB reference names weblogic-ejb-jar.xml files.
The quick fix adds the EJB reference JNDI name to the EJB bindings
file.
Use WebSphere bindings to Yes This rule detects <destination-jndi-name> for message-driven beans.
define message-driven bean JNDI
names The quick fix sets the destination JNDI name in the EJB bindings
file.
Use WebSphere bindings to Yes This rule detects <resource-env-description> elements in
define resource environment weblogic.xml or weblogic-ejb-jar.xml files.
reference JNDI names
The quick fix adds the resource reference JNDI name to the EJB
bindings file.
Use WebSphere bindings to Yes This rule detects <res-ref-name> elements in weblogic.xml or
define resource reference names weblogic-ejb-jar.xml files.
The quick fix adds the resource reference JNDI name to the EJB
bindings file.
Use WebSphere extensions to Yes This rule detect the <trans-timeout-seconds> in
define transaction timeout weblogic-ejb-jar.xml files.
seconds
The quick fix defines the timeout value to the EJB extensions file.
Use WebSphere extensions to Yes This rule detects WebLogic Server virtual directory mapping
define virtual directory mappings configuration and migrates entries to use WebSphere file serving.
Use WebSphere extensions to Yes This rule detects the <context-root> element in weblogic.xml files.
define web module context root
The quick fix defines the context root value to the Web extensions
file.
Detect Oracle auto-generated No This WebSphere Application Server traditional rule detects Oracle
keys 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 This WebSphere Application Server traditional rule detects query
Query Language constructs language elements, weblogic-ql, in weblogic-cmp-rdbms-jar.xml
files for manual migration.
Do not use WebLogic-specific Yes This WebSphere Application Server traditional rule detects
JNDI name values or the t3 non-portable WebLogic Server JNDI lookup values or URLs with
protocol the t3 or t3s protocol.
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 Yes This WebSphere Application Server traditional rule detects
define CMP mappings <weblogic-rdbms-jar> elements in weblogic-cmp-rdbms-jar.xml
files.
The following rules handle WebLogic Server JPA persistence XML migration:
The quick fix deletes the kodo property from persistence.xml files.
Use OpenJPA property names Yes This rule detects the presence of known JPA properties with a name
instead of Kodo-specific property starting with kodo.* in persistence.xml files.
names when equivalent
The quick fix renames these properties to openjpa.*.
Use OpenJPA property values Yes This rule detects the JPA properties with kodo-specific values in
instead of Kodo-specific property persistence.xml files.
values
The quick fix changes these values to valid OpenJPA values.
The following rules flag any WebLogic Server unhandled or partially handled XML file:
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.
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.
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.
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 No This rule detects <res-ref-name> elements in jboss-web.xml or
references for URLs and resource jboss.xml files that define URL resources or resource manager
managers 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 Yes This rule detects the <jndi-name> tag in jboss.xml files for EJB
define EJB JNDI names definitions.
The quick fix migrates the value found to the EJB bindings file.
Use WebSphere bindings to Yes This rule detects <ejb-local-ref> tags in jboss.xml files for EJB
define EJB local reference JNDI definitions.
names
The quick fix migrates the value found to the EJB bindings file.
Use WebSphere bindings to Yes This rule detects <ejb-ref-name> in jboss-web.xml or jboss.xml
define EJB reference names files.
The quick fix adds the JNDI name of the EJB reference to the EJB
bindings file.
Use WebSphere bindings to Yes This rule detects <destination-jndi-name> for message-driven beans.
define message-driven Bean JNDI
names The quick fix sets the destination JNDI name in the EJB bindings
file.
The quick fix adds JNDI name of the resource reference to the EJB
bindings file.
Use WebSphere extensions to Yes This rule detects the <context-root> element in jboss-web.xml files.
define web module context root
The quick fix defines the context root value in the Web extensions
file.
Do not use JBoss web services Yes This WebSphere Application Server traditional rule flags
deployment descriptor 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 Yes This WebSphere Application Server traditional rule detects
define CMP mappings <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:
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.
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.
The quick fix adds the JNDI name of the EJB reference to the EJB
bindings file.
Use WebSphere bindings to Yes This rule detects <destination-jndi-name> for message-driven beans.
define message-driven bean JNDI
names The quick fix sets the destination JNDI name in the EJB bindings
file.
Use WebSphere bindings to Yes This rule detects resource references in the orion-web.xml or
define resource reference names orion-ejb-jar.xm files.
The quick fix adds the JNDI name of the resource reference to the
EJB bindings file.
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 No This WebSphere Application Server traditional rule detects
define CMP mappings enterprise bean to relational database mappings that are used for
container-managed persistence (CMP).
Use WebSphere extensions to Yes This WebSphere Application Server traditional rule detects and
define concurrency strategy migrates the concurrency strategy used for EJB persistence.
The following rules flag any Oracle Application Server unhandled or partially handled XML file:
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.
The quick fix takes you to the refactor options to change the file
name and all of its references.
This TLD rule is selected with the competitive migration rule sets and is found under the File Review
category.
These XML file review rules are available to competitive migration rule sets.
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.
Appendix F. Third-party application server migration rules and quick fixes 101
Rule Name Quick Fix Action Taken
Do not use unsupported JTA Transaction Yes This rule flags the Spring beans that use
Manager WebSphereTransactionManagerFactoryBean or
WebLogicJtaTransactionManager or JtaTransactionManager for
transaction management. The user should use
WebSphereUowTransactionManager instead.
Appendix F. Third-party application server migration rules and quick fixes 103
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.
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 Yes This rule flags Hibernate configuration files
JPA persistence.xml (hibernate.cfg.xml) for migration to JPA configuration files
(persistence.xml).
Configuration elements that the tool does not migrate must be migrated manually to the Liberty server
configuration.
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.
Printed in USA