Application Migration Tools for Competitive Migration Built on Rational Software Analyzer technology

Application Migration Tools for Competitive Migration Built on Rational Software Analyzer technology
WebSphere Application Server
Application Migration Tools for
Competitive Migration
Built on Rational Software Analyzer technology
Version 3.5.3
A combined effort:
IBM Software Group, Application and Integration Middleware Software
IBM Software Group, Rational Software
©
Copyright IBM Corp. 2009, 2013
2 | Contents
Contents
Overview................................................................................................................................ 3
New for this release...............................................................................................................4
Version 3.5.3............................................................................................................................................ 4
Support...................................................................................................................................6
Installing and updating the migration tools....................................................................... 7
Importing applications....................................................................................................... 11
Shared Java projects............................................................................................................................... 12
EAR-level library....................................................................................................................... 12
Web module library....................................................................................................................12
Configuring a Java EE Runtime Library................................................................................................12
Configuring the migration tool for analysis..................................................................... 15
Analyzing code for migration............................................................................................ 21
Running additional rules to optimize code quality.......................................................... 24
WebSphere Application Developer Tools for Eclipse......................................................25
WebLogic Server rules and quick fixes............................................................................ 26
WebLogic
WebLogic
WebLogic
WebLogic
Server
Server
Server
Server
Java code review rules.............................................................................................. 26
JSP code review rules............................................................................................... 30
XML file review rules...............................................................................................31
File Review rules...................................................................................................... 34
JBoss Application Server rules and quick fixes............................................................... 35
JBoss
JBoss
JBoss
JBoss
Java code review rules................................................................................................................. 35
Application Server JSP code review rules................................................................................... 36
Application Server XML file review rules.................................................................................. 36
Application Server File Review rules.......................................................................................... 38
Oracle Application Server rules and quick fixes............................................................. 39
Oracle Application Server Java code review rules.................................................................................39
Oracle Application Server JSP code review rules..................................................................................39
Oracle Application Server XML file review rules................................................................................. 40
Apache Tomcat rules and quick fixes............................................................................... 43
Apache Tomcat Java code review rules................................................................................................. 43
Apache Tomcat JSP file code review rules............................................................................................ 43
Apache Tomcat XML code review rules............................................................................................... 44
Java SE version migration................................................................................................. 46
Framework migration........................................................................................................ 51
Framework XML - Spring best practices rules...................................................................................... 51
Hibernate to WebSphere JPA migration..........................................................................53
Hibernate to WebSphere JPA - Java rules............................................................................................. 53
Hibernate to WebSphere JPA - XML rules............................................................................................55
Troubleshooting.................................................................................................................. 56
Software Analyzer options not shown................................................................................................... 56
Java EE constructs or JSP not read correctly......................................................................................... 56
Logging and trace...................................................................................................................................56
Reports and history.................................................................................................................................57
Markers...................................................................................................................................................57
Known issues..........................................................................................................................................57
Copyright and trademarks.................................................................................................61
Overview | 3
Overview
Converting Java™ Platform, Enterprise Edition (Java EE) applications from one third-party application server to another
platform can be costly and time consuming. The conversion process can involve modifying Java source code, JavaServer
Pages (JSP), and deployment descriptors. The Application Migration Toolkit can assist you in performing these types of
migrations.
The application migration tools are part of the IBM® WebSphere® Application Server Migration Toolkit. This toolkit is
one part of the overall strategy for migrating from a third-party application server to IBM WebSphere Application Server.
This document explains how to install, configure, and use the following competitive migration tools:
•
•
•
•
Application Migration Tool - JBoss AS to WebSphere
Application Migration Tool - OracleAS to WebSphere
Application Migration Tool - for Apache Tomcat to WebSphere
Application Migration Tool - WebLogic to WebSphere
The tools are based on IBM Rational® Software Analyzer, which provides a single solution to identify, analyze, and
optimize the application health. The migration 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 IBM WebSphere Application Server.
The tools flag a number of known differences between applications hosted on Oracle WebLogic Server, JBoss Application
Server, Oracle Application Server, or Apache Tomcat and WebSphere Application Server. In many cases, the tools can
automatically convert the different parts to be compatible with WebSphere Application Server. If the tools are unable to
perform the fix, the file in question is flagged to identify where design changes are needed. The migration tools support:
•
•
•
•
•
•
•
•
•
•
•
Migrating applications to WebSphere Application Server Version 7.0, 8.0, or 8.5
Migrating WebLogic Server Java, JSP, and class path artifacts (Java EE 5 and prior versions)
Migrating WebLogic Server deployment descriptors (Java EE 5 and prior versions)
Migration JBoss Application Server Java and class path artifacts (Java EE 5 and prior versions)
Migrating JBoss Application Server deployment descriptors (Java EE 5 and prior versions)
Migrating Oracle Application Server Java and JSP artifacts (Java EE 5 and prior versions)
Migrating Oracle Application Server deployment descriptors (Java EE 5 and prior versions)
Migrating Apache Tomcat Java and JSP artifacts (Java EE 5 and prior versions)
Migrating Apache Tomcat Context XML information contained in the application
Migrating from Apache Tomcat 6.0 or 7.0
Java SE migration issues moving from Java SE 1.4, 5, or 6 to either Java 6 or Java 7.
The IBM WebSphere Application Server Migration Toolkit developerWorks site provides information on application
migration from a third-party application server, version-to-version application migration, and configuration migration. See
the Application Migration Tool - WebSphere Version to Version documentation for information about migrating from one
version of WebSphere Application Server to another version.
See the WebSphere Application Server V8.5 Migration Guide for comprehensive information on WebSphere Application
Server migration topics, including examples of using Application Migration Toolkit.
4 | New for this release
New for this release
Version 3.5.3
Application Migration Tool Version 3.5.3 provides the following enhancements for the competitive migration tools:
New Apache Tomcat rules
•
•
•
Migrate MBeans specific to other application servers
Do not redefine a taglib prefix using a different URI
Do not use Java keywords in JSP and JSF expression language elements
New JBoss Application Server rules
•
•
•
•
•
•
Do not use JBoss-specific naming lookup strings
Do not use JBoss-specific send or receive timeout constants
Do not use JBoss-specific string literals
Migrate MBeans specific to other application servers
Do not redefine a taglib prefix using a different URI
Do not use Java keywords in JSP and JSF expression language elements
New Oracle Application Server rules
•
•
•
Migrate MBeans specific to other application servers
Do not redefine a taglib prefix using a different URI
Do not use Java keywords in JSP and JSF expression language elements
New WebLogic Server rules
•
•
•
•
•
•
•
•
•
Do not use WebLogic-specific JNDI name values or the t3 protocol - for properties files
Do not use the WebLogic ApplicationLifecycleListener interface
Do not use the WebLogic MessageProducer API
Do not use WebLogic EJBGEN annotations
Do not use WebLogic-specific SSL protocols
Migrate MBeans specific to other application servers
Do not redefine a taglib prefix using a different URI
Do not use Java keywords in JSP and JSF expression language elements
Do not use WebLogic-specific JNDI name values or the t3 protocol
New framework rules
•
•
Detect usage of the Quartz scheduler
Check the entityInterceptor property in the Spring configuration
New Hibernate to WebSphere JPA rule set
The new rule set helps to migrate Hibernate applications to WebSphere JPA, which is based on OpenJPA standards.
The rule set contains 25 Java rules that highlight commonly used Hibernate classes and methods and provide guidance on
how to manually migrate the code to JPA. Quick fixes are not provided for the Java rules.
The rule set also includes the following two XML rules for Hibernate configuration and mapping files. The XML rules
have quick fixes to help you start creating your JPA configuration files.
New for this release | 5
•
•
Migrate Hibernate hbm.xml to JPA orm.xml
Migrate Hibernate hibernate.cfg.xml to JPA persistence.xml
See Hibernate to WebSphere JPA migration on page 53 for more information on the Hibernate rules.
File Review Category
Class Path Review is now MANIFEST.MF Review and is under the general File Review category. The File Review
category contains a new category, Properties File Review, which has a new rule to search properties files.
Reports are now being done at this higher level and will include result information for manifest or properties file rules.
Support
Bug and field support fixes have been added to this release.
The application migration tool now supports Eclipse 4.3.
6 | Support
Support
The application migration tool scans for a number of known issues in applications being 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:
•
•
•
•
For WebLogic Server, see WebLogic Server rules and quick fixes on page 26
For JBoss Application Server, see JBoss Application Server rules and quick fixes on page 35
For Oracle Application Server, see Oracle Application Server rules and quick fixes on page 39
For Apache Tomcat, see Apache Tomcat rules and quick fixes on page 43
Updates with new rules and quick fixes are made available on developerWorks®.
You can use the quick fix preview support in the migration tool 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 tool highlights these problem
areas but does not provide a quick fix.
The tool does not identify all problems. As you encounter problems that the tool does not flag, provide feedback through
the Application Migration Tool 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 tool.
If you have access to IBM Passport Advantage®, you can open a customer problem report. Other users can use the
Application Migration Tool forum to report issues or suggestions and ask questions.
The Application Migration Tools are supported on the Windows and Linux operating systems as supported by Eclipse and
Rational Application Developer.
Installing and updating the migration tools | 7
Installing and updating the migration tools
The application migration tools are Eclipse features that you install into an existing Eclipse or Rational development
environment. Supported platforms include:
•
•
•
Eclipse 3.6.2, 3.7, 4.2, and 4.3
Rational Application Developer versions 7.5 to 9.0
Rational Software Architect versions 7.5 to 8.5
You can download Eclipse from http://www.eclipse.org. Eclipse IDE for Java EE Developers is recommended for working
with Java EE applications.
To install or update this application migration tool, perform the following steps:
1. Download the latest version of the Application Migration Tool for your third-party application server from the
developerWorks site http://www.ibm.com/developerworks/websphere/downloads/migtoolkit/compmig.html, and save it
locally.
2. Start the IDE.
3. Uninstall any migration tool beta versions or versions older than V2.1.
4. 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.
Eclipse version
Install actions
Eclipse 4.3
•
•
From the Eclipse menu bar, select Help > Install New Software.
Using the Kepler update site (http://download.eclipse.org/releases/kepler),
install the BIRT Framework listed in the Business Intelligence, Reporting
and Charting feature. Also install Web, XML and Java EE Development.
Eclipse 4.2
•
•
From the Eclipse menu bar, select Help > Install New Software.
Using the Juno update site (http://download.eclipse.org/releases/juno), install
the BIRT Framework listed in the Business Intelligence, Reporting and
Charting feature. Also install Web, XML and Java EE Development.
Eclipse 3.7
•
•
From the Eclipse menu bar, select Help > Install New Software.
Using the Indigo update site (http://download.eclipse.org/releases/indigo),
install the BIRT Framework listed in the Business Intelligence, Reporting
and Charting feature. Also install Web, XML and Java EE Development.
Eclipse 3.6
•
•
From the Eclipse menu bar, select Help > Install New Software.
Using the Helios update site (http://download.eclipse.org/releases/helios),
install the BIRT Framework listed in the Business Intelligence, Reporting
and Charting feature. Also install Web, XML and Java EE Development.
Note: The catalog of available plug-ins is large and might require several minutes to download.
8 | Installing and updating the migration tools
Figure 1: Eclipse 4.2 plug-in installation dialog
5. Set up the competitive migration tool.
•
To install the previously downloaded repository archive:
1. Go to Help > Install New Software to open the installation dialog to install or update the Application
Migration Toolkit.
2. Click Add to point to your downloaded update site file.
3. In the Add Repository window, enter the following information, as shown in Figure 2: Adding a repository.
•
•
Name: Application Migration Tool
Location: Click Archive and find the compressed file that you downloaded.
Installing and updating the migration tools | 9
Figure 2: Adding a repository
4. Click OK.
6. Complete the following actions in the Install window, as shown in Figure 3: Select plug-in.
a) Select Application Migration Tool, which selects both the main feature and the other included features. The other
included features are the common feature, the JRE feature, and the framework feature. It is particularly important to
have the common feature included when upgrading.
b) Select Contact all update sites during install to find required software, and click Next.
Note: If you are installing the tool on Rational Application Developer 7.5, it is preferable to not select Uncategorized
from the repository site. These plug-ins will be installed automatically regardless of the selection. If Uncategorized is
selected, the plug-ins will not be automatically uninstalled if you uninstall the application migration tool.
Figure 3: Select plug-in
7. Click Next on the Install Details panel.
8. On the Review Licenses panel, read the terms and accept any license agreements. Click Finish. The install status
window shows the installation progress.
9. Restart the IDE when the Software Updates window is displayed.
Figure 4: Restart dialog
Importing applications | 11
Importing applications
To analyze an application for migration, the application must be imported into your Eclipse-based IDE. In order to
effectively and completely analyze the application, the application modules must be organized in projects that reflect their
structure as EAR, WAR, and EJB files. Specifically, migration rules that analyze web and EJB bindings and extensions
only work when analyzing projects created as dynamic web projects and EJB projects.
To achieve this, you can either import your existing EAR, web archive (WAR), and Enterprise JavaBeans (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, select the File > Import menu option. Select Java EE then EAR file to enter the
location of your EAR file. The Eclipse import function will create a project for the EAR file and a project for each module
in the application.
Figure 5: Importing an EAR file
By importing the application, the proper project structure is created with the deployment descriptor information. If your
EAR file contains source code, it will also get imported into the Eclipse project. However, most EAR and module files do
not contain the Java source code, and you need to copy the source code to its correct source folders. Again, use the File
> Import options 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.
When creating projects manually, create the EAR file using File > New > Enterprise Application Project option. Create
each WAR file using the File > New > Dynamic Web Project option, and create each EJB module using the File > New
> EJB Project option. Copy the source files to their correct locations in the project using the File > Import options.
Review the following guidelines for structuring projects:
•
•
•
•
Java source code for a WAR file (for example, servlet, model, or utility classes), belongs in the src folder of the
project. The src folder is defined and can be changed in the Java Build Path properties for the project. If the Java
source code needs to be referenced by more than one WAR file, see the Shared Java Projects section of this document.
Java source code for an EJB module can be placed in the ejbModule folder of the EJB project.
Precompiled Java archive (JAR) libraries for a WAR file belong in the WebContent/WEB-INF/lib folder.
EAR-level JAR libraries can be placed in the EarContent folder of the enterprise application project. If your project
contains an APP-INF/lib folder, it can be placed in the EarContent folder; however, you must run the class path
rule and its quick fix to update the class paths correctly.
12 | Importing applications
For a more detailed description of how to import applications, see the WebSphere Application Server V8.5 Migration
Guide (http://www.redbooks.ibm.com/redbooks/pdfs/sg248048.pdf).
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, refer to Java EE Deployment Assembly.
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 into the src folder of the project.
2. Right-click the project in the Project view and select Properties. 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 6: Java EE EAR module dependencies
Web module library
To create a copy of the JAR file in each WAR file, complete the following steps:
1. Open the Properties dialog of the web project.
2. Right-click the project in the Project view and select Properties. 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.
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. Open the Eclipse preferences by choosing Preferences under the Eclipse Window menu.
2. Navigate to the Server > Runtime Environments item on the left pane.
Importing applications | 13
Figure 7: Server Runtime Environments
3. Click Add. Select Basic > J2EE Runtime Library.
4. On the next wizard page, click Browse to choose the library location, locate the dev/JavaEE folder of your
WebSphere Application Server installation, and select the appropriate Java EE version. That folder contains the
j2ee.jar file with the Java EE APIs.
To use this runtime library in a web or EJB project, go to the project properties dialog. Right-click the project in the
Project view, select Properties, and choose the Targeted Runtimes item.
Figure 8: Targeted Runtimes
In the Targeted Runtimes window, select the check box next to the recently configured Java EE runtime library, and click
OK.
You can achieve the same effect by targeting WebSphere Application Servers and the Liberty Profile when you have the
WebSphere Application Server Developer Tools installed.
Configuring the migration tool for analysis | 15
Configuring the 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 a migration tool installed, you have new analysis options to configure and run an
analysis. You can access the options in the Eclipse Run menu, in the Launch toolbar, and in the explorer pop-up menus.
The following figure demonstrates the different ways you can run the analysis using the application migration tools.
From the Eclipse menu:
From the Launch Eclipse toolbar:
From the explorer pop-up menu:
Figure 9: Options for running the tool
If you do not see Software Analyzer options, see Software Analyzer options not shown on page 56.
To configure the analysis using the toolbar, complete the following steps:
1. On the toolbar, select Software Analyzer (
configuration dialog.
) > Software Analyzer Configurations to display the main
You can add or remove analysis configurations by using the icons in the dialog.
16 | Configuring the migration tool for analysis
Figure 10: Creating a new Software Analyzer configuration
2. In the configurations list, select Software Analyzer. Then, click New
the basic configuration interface.
. The right side of the dialog changes to show
Configuring the migration tool for analysis | 17
Figure 11: Setting up the configuration
3. In the Software Analyzer Configurations dialog, 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 on this dialog to analyze a working set or a selection
of projects.
Tip: When you use the explorer pop-up menu to run your analysis, the scope of the analysis is limited to the node in
the project where the menu item was selected. This allows you to perform a quick analysis on a limited set of code.
5. On the Rules tab, select the type of analysis to perform using the Rule Sets list. You can also select individual rules to
run.
Tip: To obtain additional information about a rule, highlight the rule and press F1 (Shift-F1 for Linux). Help for
the rule is shown in the configuration dialog. The initial help page includes a short description and a link to more
information.
18 | Configuring the migration tool for analysis
Figure 12: Selecting rules
There are four migration-related rule sets, WebLogic Application Migration, JBoss Application Migration, Oracle
Application Migration, and Tomcat Application Migration.
The migration tools have rules under the following analysis providers:
•
•
•
•
File Review
Java Code Review
JSP Code Review
XML File Review
After you select a rule set, click Set to select the applicable application migration rules.
Configuring the migration tool for analysis | 19
Figure 13: Configuring a rule set
Select the target WebSphere Application Server version and the source Java version. If the target WebSphere
Application Server version is V8.5, you can also select the target Java version, Java 6 or Java 7. Select Final target is a
Liberty profile server running on Oracle Java only if you are not using an IBM-supplied Java Runtime Environment
with the Liberty profile server.
Note: The number of rules in the analysis configuration dialog 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. You can use the Software Analysis Configurations dialog to 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 dialog 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 the Apply button.
d) Click the Analyze button.
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 14: Rule properties
Analyzing code for migration | 21
Analyzing code for migration
Run the analysis and display the results.
To start the analysis, click Analyze on the Configuration dialog.
The results are displayed in the Software Analysis Results view.
Figure 15: Java Code Review results view
Depending on which rules you are running, the content of the results view might vary. The results generated by a
migration tool are displayed in one of the following tabs:
•
•
•
•
File Review
Java Code Review
JSP Code Review
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.
22 | Analyzing code for migration
Figure 16: Result options with Quick Fix Preview and Help
Not all rules have all actions available, but the possible actions include:
• 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.
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.
Analyzing code for migration | 23
•
•
•
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.
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.
Context-sensitive help is displayed in the Help view as you select each result. The first panel is a short description. Click
Detailed Help to get more information. Press F1 to open the Help view if it is not already displayed.
24 | Running additional rules to optimize code quality
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: Other architectural and Java rules 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.
WebSphere Application Developer Tools for Eclipse | 25
WebSphere Application Developer Tools for Eclipse
If you are using the Eclipse IDE for application development, there are a number of tools available that can be used with
the migration toolkit that enable you to migrate, develop, deploy, and test within a single lightweight Eclipse IDE. Tools
are available for both the traditional WebSphere Application Server and the new Liberty profile server.
•
•
•
•
IBM WebSphere Application Server v8.5 Liberty Profile Developer Tools
IBM WebSphere Application Server v8.5 Developer Tools
IBM WebSphere Application Server v8.0 Developer Tools
IBM WebSphere Application Server v7.0 Developer Tools
These tools are available from the Eclipse Marketplace and can be installed easily from within Eclipse:
1.
2.
3.
4.
5.
Start your Eclipse workbench.
Click Help > Check for Updates to install the latest updates.
Click Help > Eclipse Marketplace.
In the Find field, type WebSphere.
In the list of results, locate the appropriate WebSphere Application Server Developer Tools and then click Install.
The tools provide function and features for the capabilities of their targeted release of WebSphere. They also contain
functionality for managing the server, publishing to a local or remote server, and for controlling incremental publishing.
For general discussion, demos, and information links, go to http://wasdev.net for more information.
The Liberty profile provides a simplified application server runtime environment that makes testing web applications much
easier for the developer. The corresponding WebSphere Application Server V8.5 Liberty Profile Developer Tools support
the development, assembly, and deployment of web applications to servers based on the WebSphere Application Server
V8.5 Liberty profile server. To get started with the Liberty profile server, see The Liberty profile. Also see, Liberty profile:
Feature management to understand the Liberty profile server supported features and capabilities.
26 | WebLogic Server rules and quick fixes
WebLogic Server rules and quick fixes
The Application Migration Tool - WebLogic to WebSphere feature evaluates Java code, JSP code, deployment descriptors,
and web services deployment descriptors as part of its analysis set.
When you select the WebLogic Application Migration rule set, relevant WebLogic Server rules, framework rules, and
Java SE rules will be selected. The WebLogic Server specific rules are described in this section. The Java SE rules are
described in Java SE version migration on page 46. 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 51.
WebLogic Server Java code review rules
Under the Java Code Review set of rules, the WebLogic to WebSphere code migration category contains multiple rules.
For more information, press F1 when viewing the rule in the configuration dialog or in the results viewer.
Rule Name
Quick
Fix
Action Taken
Detect Apache Beehive packages
No
This rule detects the use of Apache Beehive packages
(org.apache.beehive).
Do not put EJB classes in default
Java packages
No
This rule detects Java classes that define EJBs that are in default Java
packages. WebSphere does not allow EJBs in default Java packages.
Do not start threads within the
web or EJB containers
No
This rule detects code within web or EJB modules that starts or runs
threads.
Do not use Apache XMLBeans
packages
No
This rule detects references to the Apache XMLBeans package
org.apache.xmlbeans.
Do not use Commons Logging
system level property
Yes
This rule detects setting the commons logging implementation class
using the system property.
The quick fix removes the entry.
Do not use invalid JPA imports
No
This rule detects the use of specific kodo import statements that do not
have equivalent openJPA imports.
These references are flagged so you can evaluate their usage and
migrate manually.
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 openJPA equivalent
Yes
This rule detects JPA properties that start with kodo.* in java files
but have no equivalent openJPA values.
The quick fix removes these properties.
Do not use non-mapping
weblogic.apache packages
No
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.
WebLogic Server rules and quick fixes | 27
Rule Name
Quick
Fix
Action Taken
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 or
EntityManagerFactory for
injected JPA elements
Yes
Do not use the WebLogic
ApplicationLifecycleListener
interface
No
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
TransactionHelper
getUserTransaction method
No
This rule detects the use of the
weblogic.transaction.TransactionHelper getUserTransaction method.
Do not use UserTransaction
interface from CMT beans
No
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.
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.
These references are flagged so that you can remove this Java EE
violation.
Do not use weblogic.apache
packages
Yes
This rule detects import and code references to classes where the class
package starts with weblogic.apache and the class maps directly
to an org.apache class.
The quick fix changes the code to org.apache. Download the
appropriate Apache open source .jar file, and include it with your
application.
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.
28 | WebLogic Server rules and quick fixes
Rule Name
Quick
Fix
Action Taken
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
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.
Do not use WebLogic RMI API
calls
Yes
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.
Do not use WebLogic-specific
JNDI name values
Yes
The quick fix migrates the objects used in the Environment
references to a hash table used to initialize the InitialContext
object.
This rule detects the use of the following proprietary JNDI name
values:
•
•
java.naming.factory.initial = weblogic.jndi.
WLInitialContextFactory
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:
WebLogic Server rules and quick fixes | 29
Rule Name
Quick
Fix
Action Taken
•
•
java.naming.factory.initial = com.ibm.websphere.naming.
WsnInitialContextFactory
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 serverspecific 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
No
TransactionSynchronizationRegistry
object
This rule detects the use of the
TransactionSynchronizationRegistry object and flags it
for manual migration.
Do not use WebLogic WLLevel
object
This rule detects WLLevel object usage in a setLevel() method.
Yes
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().
30 | WebLogic Server rules and quick fixes
Rule Name
Quick
Fix
Action Taken
Within servlets, Web applications and client code, the flagged line
is converted to the JNDI lookup: ctx.lookup("java:comp/
UserTransaction")
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 of Kodo-specific property
names when equivalent
Yes
Use OpenJPA property values
instead of Kodo-specific property
values
Yes
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.
This rule detects the presence of known JPA properties with a name
starting with kodo.* in Java files.
The quick fix renames these properties to openjpa.*.
This rule detects the JPA properties with kodo specific values in Java
files.
The quick fix changes these values to valid openJPA values.
The quick fix adds the missing values to offer similar behavior to
WebLogic Server automated deployment.
WebLogic Server JSP code review rules
Under the JSP code review set, the WebLogic to WebSphere JSP Migration category has rules described in the following
table. For more information, press F1 when viewing the rule in the results viewer.
Rule Name
Quick
Fix
Action Taken
Avoid using a .jsp extension for
JSP fragments
Yes
This rule detects JSP fragments included in another JSP file. If the JSP
fragment file has the .jsp extension rather than .jspf extension, it is
flagged.
The quick fix takes you to the refactor dialog to change the file name
and all of its references.
Check for valid configuration of
the getQueryString method in
JSP welcome files
No
This rule detects the method call request.getQueryString() in JSP
welcome files of a web module. These calls are flagged so the user can
verify correct usage 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.
WebLogic Server rules and quick fixes | 31
Rule Name
Quick
Fix
Action Taken
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
JSP taglib attributes are case-sensitive in WebSphere Application
Server. This rule detects any taglib attribute that is not case correct.
The quick fix changes the case as it is defined in the tag library.
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
Detect Oracle auto-generated
keys
No
This 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 local JNDI names
Yes
This rule detects <local-jndi-name> tags in weblogic-ejbjar.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.
Do not use WebLogic servlet
filter for XML parsing
Yes
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.
Do not use WebLogic-specific
EJB Query Language constructs
No
This 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
Yes
This rule detects non-portable WebLogic Server JNDI lookup values
or URLs with the t3 or t3s protocol.
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
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.
32 | WebLogic Server rules and quick fixes
Rule Name
Quick
Fix
Action Taken
Use WebSphere bindings to
define EJB reference names
Yes
This rule detects <ejb-ref-name> in weblogic.xml or weblogicejb-jar.xml files.
The quick fix adds the EJB reference JNDI name to the EJB bindings
file.
Use WebSphere bindings to
define message-driven bean JNDI
names
Yes
Use WebSphere bindings to
define resource environment
reference JNDI names
Yes
Use WebSphere bindings to
define resource reference names
Yes
This rule detects <destination-jndi-name> for message-driven beans.
The quick fix sets the destination JNDI name in the EJB bindings file.
This rule detects <resource-env-description> elements in
weblogic.xml or weblogic-ejb-jar.xml files.
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 CMP mappings
Yes
This rule detects <weblogic-rdbms-jar> elements in weblogiccmp-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 weblogicejb-jar.xml files.
The quick fix moves the Exclusive, ReadOnly, Database, and
Optimistic options to the EJB extensions file.
Use WebSphere extensions
to define transaction timeout
seconds
Yes
Use WebSphere extensions to
define virtual directory mappings
Yes
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.
This rule detect the <trans-timeout-seconds> in weblogic-ejbjar.xml files.
The quick fix defines the timeout value to the EJB extensions file.
The quick fix defines the context root value to the Web 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.
WebLogic Server rules and quick fixes | 33
Rule Name
Quick
Fix
Action Taken
The quick fix removes the servlet along with its servlet mapping
elements.
Do not use kodo properties that
have no openJPA equivalent
Yes
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.
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.
The following rule migrates web services within your application:
Rule Name
Quick
Fix
Action Taken
Do not use WebLogic web
services deployment descriptor
Yes
This 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.
WebLogic Server File Review rules
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 file content.
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.
JBoss Application Server rules and quick fixes | 35
JBoss Application Server rules and quick fixes
The Application Migration Tool - JBoss to WebSphere feature evaluates Java code, JSP code, deployment descriptors, and
web services deployment descriptors from JBoss Application Server applications as part of its analysis set. The following
rules and quick fixes are available to help migrate JBoss Application Server applications.
When you select the JBoss Application Migration rule set, relevant JBoss Application Server rules, framework rules, and
Java SE rules will be selected. The JBoss Application Server specific rules are described in this section. The Java SE rules
are described in Java SE version migration on page 46. 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 51.
JBoss Java code review rules
Under the Java code review set of rules, the JBoss to WebSphere code migration category contains multiple rules. For
more information, press F1 when viewing the rule in the configuration dialog or in the results viewer.
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 JNDI
name values
Yes
This rule detects the use of these JNDI name values:
•
•
java.naming.factory.initial = org.jnp.interfaces.
NamingContextFactory
java.naming.provider.url = jnp://localhost:1099
If found, users are given the option to change the JNDI names to
default portable JNDI name values:
•
•
java.naming.factory.initial = com.ibm.websphere.naming.
WsnInitialContextFactory
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
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.
36 | JBoss Application Server rules and quick fixes
Rule Name
Quick
Fix
Action Taken
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.
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.
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 names
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.
JBoss Application Server JSP code review rules
Under the JSP code review set, the JBoss to WebSphere JSP migration category has rules described in the following
table. For more information, press F1 when viewing the rule in the results viewer.
Rule Name
Quick
Fix
Action Taken
Avoid using a .jsp extension for
JSP fragments
Yes
This rule detects JSP fragments included in another JSP file. If the JSP
fragment file has the .jsp extension rather than .jspf extension, it is
flagged.
The quick fix takes you to the refactor dialog to change the file name
and all of its references.
Check for the getQueryString
method in JSP welcome files
No
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.
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.
JBoss Application Server rules and quick fixes | 37
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.
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
define message-driven Bean
JNDI names
Yes
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.
This rule detects <destination-jndi-name> for message-driven beans.
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
define CMP mappings
Yes
This rule detects <jbosscmp-jdbc> elements in jbosscmpjdbc.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.
Use WebSphere extensions to
define web module context root
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.
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
No
This rule flags the jboss-web.xml file so that you can look for any
unmigrated elements at the end of the application migration.
The following rule migrates web services within your application:
Rule Name
Quick
Fix
Action Taken
Do not use JBoss web services
deployment descriptor
Yes
This 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.
JBoss Application Server File Review rules
Under File Review category, the JBoss to WebSphere class path migration category 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 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.
Oracle Application Server rules and quick fixes | 39
Oracle Application Server rules and quick fixes
The Application Migration Tool - OracleAS to WebSphere feature evaluates Java code, JSP code, deployment descriptors,
and web services deployment descriptors from Oracle Application Server applications as part of its analysis set. The
following rules and quick fixes are available to help migrate Oracle Application Server applications.
When you select the Oracle Application Migration rule set, relevant Oracle Application Server rules, framework rules,
and Java SE rules will be selected. The Oracle Application Server specific rules are described in this section. The Java
SE rules are described in Java SE version migration on page 46. 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 51.
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. For
more information, press F1 when viewing the rule in the configuration dialog or in the results viewer.
Rule Name
Quick
Fix
Action Taken
Do not cast java.sql.Connection
as OracleConnection directly
No
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.
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
Under the JSP code review set, the Oracle to WebSphere JSP Migration category has rules described in the following
table. For more information, press F1 when viewing the rule in the results viewer.
40 | Oracle Application Server rules and quick fixes
Rule Name
Quick
Fix
Action Taken
Avoid using a .jsp extension for
JSP fragments
Yes
This rule detects JSP fragments included in another JSP file. If the JSP
fragment file has the .jsp extension rather than .jspf extension, it is
flagged.
The quick fix takes you to the refactor dialog to change the file name
and all of its references.
Check for the getQueryString
method in JSP welcome files
No
This rule detects the request.getQueryString method call 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 flags JSP expression language (EL) elements with variables
names that contain Java keywords or EL reserved keywords.
Do not use proprietary Oracle tag
libraries
No
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 orionapplication.xml file.
Do not use MDB 2.0 listener
ports
No
This rule detects the message-driven bean (MDB) 2.0 listener ports in
the ejb-jar.xml file.
Do not use Oracle global loadon-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 login modules
No
This rule detects login modules that are marked with <login-modules>
tag in the orion-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-webapplication.xml file.
Do not use Oracle-specific web
filters
Yes
This rule detects the use of web filters that start with "oracle." defined
in the web.xml.
The quick fix deletes the filter element.
Oracle Application Server rules and quick fixes | 41
Rule Name
Quick
Fix
Action Taken
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.
Use WebSphere bindings to
define EJB reference names
Yes
This rule detects EJB references in the orion-web.xml or orionejb-jar.xml files.
The quick fix adds the JNDI name of the EJB reference to the EJB
bindings file.
Use WebSphere bindings to
define message-driven bean JNDI
names
Yes
Use WebSphere bindings to
define resource reference names
Yes
This rule detects <destination-jndi-name> for message-driven beans.
The quick fix sets the destination JNDI name in the EJB bindings file.
This rule detects resource references in the orion-web.xml or
orion-ejb-jar.xm files.
The quick fix adds the JNDI name of the resource reference to the EJB
bindings file.
Use WebSphere configuration to
control class loader order
No
This rule detects the presence of the search-local-classes-first setting
used to control class loading order.
Use WebSphere extensions to
define CMP mappings
No
This 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 rule detects and migrates the concurrency strategy used for EJB
persistence.
The quick fix locates the concurrency strategy settings in the orionejb-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.
Rule Name
Quick
Fix
Action Taken
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.
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.
The following rule migrates web services within your application:
Rule Name
Quick
Fix
Action Taken
Do not use Oracle web services
deployment descriptor
Yes
This rule flags oracle-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.
Apache Tomcat rules and quick fixes | 43
Apache Tomcat rules and quick fixes
The Application Migration Tool - for Apache Tomcat to WebSphere feature evaluates Java code, JSP code, and
deployment descriptors and XML files from Apache Tomcat applications as part of its analysis set. The following rules
and quick fixes are available to help migrate Apache Tomcat applications.
When you select the Tomcat Application Migration rule set, relevant Tomcat rules, framework rules, and Java SE
rules will be selected. The Tomcat specific rules are described in this section. The Java SE rules are described in Java SE
version migration on page 46. 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 51.
Apache Tomcat Java code review rules
Under the Java code review set of rules, the Apache Tomcat to WebSphere code migration category contains multiple
rules. For more information, press F1 when viewing the rule in the configuration dialog or in the results viewer.
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.
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 JSP file code review rules
Under the JSP code review set, the rules in the Apache Tomcat to WebSphere JSP migration category described in the
following table. For more information, press F1 when viewing the rule in the results viewer.
44 | Apache Tomcat rules and quick fixes
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 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 the .jsp extension rather than .jspf extension, it is
flagged.
The quick fix takes you to the refactor dialog to change the file name
and all of its references.
Check for the getQueryString
method in JSP welcome files
No
This rule detects the method call request.getQueryString() in JSP
welcome files of a web module. These calls are flagged so the user can
verify correct usage 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.
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 METAINF/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
welcome file name
Yes
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 METAINF/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 METAINF/Context.xml file to the web.xml file and WebSphere
bindings.
Apache Tomcat rules and quick fixes | 45
Rule Name
Quick
Fix
Action Taken
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 METAINF/Context.xml file to the web.xml file.
Use Java EE deployment
descriptors to define environment
references
Yes
This rule migrates Context Environment information from the METAINF/context.xml file to the web.xml file.
Use Java EE deployment
descriptors to define missing
security roles
Yes
This rule flags <auth-constraint> elements in web.xml that
are missing associated security-role elements.
46 | Java SE version migration
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, or Java SE 6. Java migration targets are Java SE 6 and Java SE 7.
The Sun to IBM Java compatibility impacts category provides a set of rules to migrate Sun APIs that are not
available on the IBM Java Runtime Environment. Where possible, the rules migrate the code to use javax.net or
com.ibm.net.ssl classes.
The specific rules selected depends on your selection of the source Java Runtime Environment that your application
previously used and the version of WebSphere you are migrating to. For WebSphere Application Server V8.5, you can
choose either Java SE 6 or Java SE 7 as your target.
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.
Table 1: 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:
•
•
•
•
•
•
•
org.w3c.dom.Attr
org.w3c.dom.Document
org.w3c.dom.DOMImplementation
org.w3c.dom.Element
org.w3c.dom.Entity
org.w3c.dom.Node
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.
Java SE version migration | 47
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.
2.
3.
4.
5.
org.apache.crimson.*
org.apache.xml.*
org.apache.xalan.*
org.apache.xpath.*
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()
method explicitly when deriving a string
value
No
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.
48 | Java SE version migration
Rule Name
Quick
Fix
Action Taken
Use the BigDecimal toPlainString()
method instead of the toString() method
Yes
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.
The quick fix changes toString to toPlainString.
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.
Table 2: 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 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.
Table 3: 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.
Java SE version migration | 49
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
setBackground method
No
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.
Run the following rules when you are migrating your application from an Oracle Java Runtime Environment to an IBM
Java Runtime Environment. If you are running Liberty profile server using an Oracle Java Runtime, do not run the quick
fixes for these rules.
Table 4: 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
com.sun.net.ssl.internal.ssl.Provider
Yes
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.
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 5: 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.
Framework migration | 51
Framework migration
Under the Java Code Review and the XML File Review categories of rules, the Framework migration category
contains rules for recognizing some of the commonly used frameworks that might need changes to work on WebSphere
Application Server. The framework rules described in this section are automatically selected with the competitive tool rule
sets.
The following Java or XML framework detection rules trigger only once per project to let you know the framework was
detected. The rules provide information to help you verify that the framework is compatible with WebSphere Application
Server.
Table 6: Framework migration
Rule Name
Quick
Fix
Action Taken
Check for the Hibernate framework
No
This rule scans Java and XML artifacts to detect the use of the
Hibernate framework.
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.
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
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.
No
Rule Name
Quick
Fix
Action Taken
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 contextparam 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
Manager
Yes
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 | 53
Hibernate to WebSphere JPA migration
The Hibernate to WebSphere JPA rule set provides Java and XML rules that migrate Hibernate application interfaces
and methods and Hibernate configuration XML to WebSphere JPA equivalents. These rules are made available as a
separate rule set and are not automatically selected with the competitive tool rule sets.
Hibernate to WebSphere JPA - Java rules
The Hibernate to WebSphere JPA Java rules are located under the Java Code Review > Framework migration
category of rules. These rules provide information on how to migrate commonly used Hibernate interfaces and methods.
You must manually migrate your Hibernate code to WebSphere JPA. For migration guidance, use the information and
samples in the detailed help for each rule.
Table 7: 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
54 | Hibernate to WebSphere JPA migration
Rule Name
Quick
Fix
Action Taken
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.
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.
Hibernate to WebSphere JPA migration | 55
Rule Name
Quick
Fix
Action Taken
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
method
No
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.
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.
56 | Troubleshooting
Troubleshooting
Software Analyzer options not shown
Installing an application migration tool creates a Software Analyzer menu and toolbar options in the Java, Debug, Plugin 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 Importing applications on page 11 for more information.
Logging and trace
The application migration tools write error information to two log files:
•
•
The workspace log (workspace/.metadata/.log) contains messages logged by the application migration tools
and messages logged by Rational Software Analyzer.
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:
Troubleshooting | 57
•
Command-line option. Add the system variable to the command line that starts Eclipse:
•
eclipse.exe -vmargs -Dappconversion.trace=true
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
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 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:
•
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.
58 | Troubleshooting
•
•
Choose Run in Background to prevent all the editors from opening and possibly running out of window handles.
Disable the automatic build feature of Eclipse (Project > Build Automatically) while running Quick Fix All
Category. Manually build the projects, and enable the option again after running Quick Fix All Category.
Process all rules of a category before running analysis again.
Some rules are interrelated, and you might improve results if you run related quick fixes before running the analysis again.
For example, the triggers for the WebLogic Server logging rules are related, and you will need to apply all quick fixes
related to logging to make sure that the changes can compile successfully.
Multiple rules on the same node
When multiple rules are flagged on the same node, only the first quick fix applied runs correctly. You might need to run
the analysis multiple times to make sure that all code is fixed and processed correctly.
Viewing external links from help in Linux
Many detailed help pages have external references to information applicable to the specific rule. This information is best
viewed from an external browser rather than the Eclipse help view. On Windows platforms, help automatically launches
these external references in the default browser. On Linux 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 (
page.
) on the detailed help
Java Architectural Discovery rules
The Java Architectural Discovery rules are not supported in Rational Application Developer 7.5.x. These rules depend
on APIs in Eclipse 3.5 and higher. Do not select the Java Architectural Discovery rules if your development environment
is based on Eclipse 3.4.x.
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.
Uncategorized plug-ins
If you are installing the tools on Rational Application Developer 7.5, it is preferable to not select Uncategorized from the
repository site. If you select Uncategorized and later want to uninstall the tool, you must manually uninstall these plugins:
•
•
•
•
•
•
•
•
•
•
•
Analysis Reporting nl1 version
Analysis Reporting nl2 version
Command Line Analysis
Command Line Analysis nl1 version
Command Line Analysis nl2 version
Compatibility feature
Core_feature Feature
JEE Code Review
JEE Code Review nl1 version
JEE Code Review nl2 version
J2SE Code Review
Troubleshooting | 59
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
J2SE Code Review nl1 version
J2SE Code Review nl2 version
Java Architectural Discovery
Java Code Review Feature Translations
Java Globalization Code Review
Java Globalization Code Review nl1 version
Java Globalization Code Review nl2 version
Java Security Code Review
Java Security Code Review nl1 version
Java Security Code Review nl2 version
ODA Compatability Feature
Rational Code Analyst Core Services Feature
Rational Software Analyzer Architecture Core
Rational Software Analyzer Code Review Core
Rational Software Analyzer Java Code Review
Rational Software Analyzer Reporting
Rational Software Analyzer Reporting ODA
RCA Analysis Feature Translations
This problem does not occur in Eclipse 3.5 and higher.
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:
•
Produce a PDF file instead of an HTML file.
•
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.
Copyright and trademarks | 61
Copyright and trademarks
©
Copyright IBM Corporation 2009, 2013.
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.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement