WAS v8.0 > Migration and coexistence > Distributed operating systems > Migrate product configurations
Configuration mapping during product-configuration migration
Supported configurations
The Application Migration Toolkit for WAS provides support for migrating applications from previous versions of WAS to the latest product version.
Migration always involves migrating a single profile to another single profile on the same machine or a separate machine. Examples include...
- WAS v6.x dmgr migrating to a v8.0 dmgr
- WAS v6.x appserver migrating to a v8.0 stand-alone appserver
The migration tools map objects and attributes existing in the version from which you are migrating to the corresponding objects and attributes in v8.0.
| Bootstrap port | The migration tools carry the old release value into the v8.0 environment. If a value for the -portBlock parameter is specified during the call to WASPostUpgrade, however, a new port value is given to each appserver that is migrated to v8.0. | ||||||||||||||||||
| Command-line parameters | The migration tools convert appropriate command-line parameters to JVM settings in the server process definition. Most settings are mapped directly. Some settings are not migrated because their roles in the WAS v8.0 configuration do not exist, have different meanings, or have different scopes. | ||||||||||||||||||
| Generic servers | In v6.x and later, a generic server has its own type, called GENERIC_SERVER. Migration will perform this conversion, but migration cannot accurately migrate the external resources that the generic server references. After migration has completed migrating the generic server settings, you might need to perform additional tasks. If the old resource that the generic server was managing is located under the old WAS installation...
If the old resource that the generic server was managing is not installed under the oldWAS installation, nothing further is required. | ||||||||||||||||||
| Java heap size for migrating EAR files | When migrating all WAS v6.x or above EAR files to v8.0 using wsadmin.sh, the WASPostUpgrade tool uses the default maximum Java heap size value of 64 MB to install the EAR files. If a v6.x or above EAR file fails to install during migration because the Java heap size is not large enough, you see a message similar to the following message: java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError Increase the maximum Java heap size, and follow the example below to install the application. Example of installing the application on WAS v8.0... Assume that:
wsadmin -conntype NONE
-c "$AdminApp install C:\\WebSphere\\AppServer\\installableApps\\EAR_file_name
{-nodeployejb
-appname app_name
-server server_name
Example of installing the application on WAS WAS, ND v8.0... Assume that:
wsadmin -conntype NONE
-c "$AdminApp install
C:\\WebSphere\\ Manager\\installableApps\\EAR_file_name>
{-nodeployejb
-appname app_name
-cluster cluster_name}"
| ||||||||||||||||||
| JMS server | The JMS server was changed in WAS v6.x from type MESSAGE_BROKER to type APPLICATION_SERVER. Any queues or topics that it owned have been migrated into the default messaging provider, which is based on service integration technologies. All JMS resources were left untouched and should work without modification. Further migration of these resources can be performed by running scripts or bats provided by the v8.0 default messaging provider. | ||||||||||||||||||
| Migration of a v6.x or above node to a v8.0 node | We can migrate a WAS v6.x or above node that belongs to a cell without removing the node from the cell. Migrate the dmgr first, before migrating any base nodes in the cell. Use the same cell name when migrating WAS ND from v6.x or above to v8.0. If you use a different cell name, federated nodes cannot successfully migrate to the WAS, ND v8.0 cell. Migrate a base WAS node that is within a cell to v8.0 also migrates the node agent to v8.0. A cell can have some v8.0 nodes and other nodes that are at v6.x or above levels. Read Coexistence support for information on restrictions on using mixed-release cells. | ||||||||||||||||||
| Policy files | WAS v8.0 migrates all the policy files that are installed with v6.x or above by merging settings into the v8.0 policy files with the following characteristics:
| ||||||||||||||||||
| Properties directories | Migration copies files from prior version directories into the WAS v8.0 configuration. | ||||||||||||||||||
| Property files | WAS v8.0 migrates all the property files that are installed with v6.x or above by merging settings into the v8.0 property files. | ||||||||||||||||||
| Resource adapter archives (RARs) referenced by J2C resources | RARs that are referenced by J2C resources are migrated if those RARs are in the old WAS installation. In this case, the RARs are copied over to the corresponding location in the new WAS installation. Relational Resource Adapter RARs will not be migrated. Migrating cluster-level resources: WAS v6.0 introduced the concept of cluster-level resources. These are configured in resourcexxx.xml files under the cluster directories. For example:
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172"
name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar"> ...
</resources.j2c:J2CResourceAdapter>
If we have a cluster-level resource, this resource must be in the same location on each cluster member (node). Using the above example, therefore, each cluster member must have the RAR file installed at location ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} is resolved on each cluster member to get the exact location. In the migration of a dmgr, the tools migrate the cluster files on the dmgr, including the resourcexxx.xml files. In the migration of a federated node, the tools process each J2C adapter. RAR files in a v6.x to v8.0 migration: Migration from v6.x to v8.0 copies files such as RAR files from WAS_INSTALL_ROOT to WAS_INSTALL_ROOT and from USER_INSTALL_ROOT to USER_INSTALL_ROOT. If we have a RAR file in the WAS_INSTALL_ROOT for v6.x, for example, the migration tools do not automatically copy the file from WAS_INSTALL_ROOT to USER_INSTALL_ROOT. This maintains the integrity of the cluster-level J2C resources. If you hardcoded a path to a RAR file (archivePath="C:/WAS/installedConnectors/x2.rar" for example) in v6.x, however, the v8.0 migration tools cannot change the archivePath attribute to reflect this because that would break all of the other cluster members that have not been migrated. | ||||||||||||||||||
| Samples | No migration of samples from previous versions is available. There are equivalent WASv8.0 samples that you can install. | ||||||||||||||||||
| Security | Java 2 security is enabled by default when you enable security in WAS v8.0. Java 2 security requires you to grant security permissions explicitly. There are several techniques that you can use to define different levels of Java 2 security in v8.0. One is to create a was.policy file as part of the application to enable all security permissions. The migration tools call the wsadmin command to add an existing was.policy file in the v8.0 properties directory to enterprise applications as they are being migrated. When migrating to WASv8.0, your choice of whether or not to migrate to support script compatibility results in one of two different outcomes.
| ||||||||||||||||||
| Stdin, stdout, stderr, passivation, and working directories | The location for these directories is typically within the installation directory of a previous version. The default location for stdin, stdout, and stderr is the logs directory of the WAS v8.0 installation root. The migration tools attempt to migrate existing passivation and working directories. Otherwise, appropriate v8.0 defaults are used. | ||||||||||||||||||
| Transport ports | The migration tools migrate all ports. We must resolve any port conflicts before you can run servers at the same time. If ports are already defined in a configuration being migrated, the migration tools fix the port conflicts in the v8.0 configuration and log the changes for your verification. If you specify the -portBlock parameter in the WASPostUpgrade command, a new value is assigned to each transport that is migrated. If you specify true for the -replacePorts parameter in the WASPostUpgrade command, all port values from the old configuration are used in the new configuration. If you specify false for the -replacePorts parameter, the default port definitions in the new profile are not replaced with the values from the old configuration during migration. For more information on the WASPostUpgrade command, read WASPostUpgrade command. For further information on transport chains and channels, read the 'Transport chains' article in the information center. We must manually add virtual host alias entries for each port. For more information, read the "Configuring virtual hosts" article in the information center. | ||||||||||||||||||
| Web modules | The specification level of the Java EE implemented in WAS v6.0.x required behavior changes in the web container for setting the content type. If a default servlet writer does not set the content type, not only does the web container no longer default to it but the web container returns the call as "null." This situation might cause some browsers to display resulting web container tags incorrectly. To prevent this problem from occurring, migration sets the autoResponseEncoding IBM extension to "true" for web modules as it migrates enterprise applications. | ||||||||||||||||||
| JVM system properties | If you migrate a v6.1 configuration that has feature packs installed, the migration tools might add one or two JVM system properties for each Java server in the configuration, including your administrative servers. Web servers are not affected. The properties are set to indicate to the JVM that the configuration should use a Java annotation scan policy other than the v8.0 default scan policy.
If these properties are set, the following two changes take place in the default v8.0 behavior:
We can change the scan policy behavior by adding or removing the custom JVM system properties from your server.xml files. To evoke the correct installApp behavior, the server.xml file for the dmgr must retain any property specified for any node in the cell. After changing the properties, reinstall or update the applications and then resynchronize the cell to implement the change. |
Avoid trouble: In a coexistence scenario, using common directories between versions can create problems.
Migrate product configurations