Various configurations are mapped during product-configuration migration.
This article is about configuration migration, such as migrating deployment managers and federated nodes in a network deployment environment. The Application Migration Toolkit for WebSphere Application Server provides support for migrating applications from previous versions of WebSphere Application Server to the latest product version. For information about migrating applications, read more about the Application Migration Toolkit.
sptcfg Migration always involves migrating
a single profile to another single profile on the same machine or
a separate machine. Examples include a WebSphere® Application Server Version 6.1 deployment
manager migrating to a Version 8.5 deployment manager and a Version 6.1 application server migrating
to a Version 8.5 stand-alone
application server.
Many migration scenarios are possible. The migration tools map objects and attributes existing in the version from which you are migrating to the corresponding objects and attributes in the Version 8.5 environment.
The migration tools carry the old release value into the Version 8.5 environment.
If a value for the -portBlock parameter is specified during the call to WASPostUpgrade, however, the specified port value is given to each application
server that is migrated to Version 8.5.
The migration tools convert appropriate command-line parameters to Java Virtual Machine (JVM) settings in the server process definition. Most settings are mapped directly. Some settings are not migrated because their roles in the WebSphere Application Server Version 8.5 configuration do not exist, have different meanings, or have different scopes.
For information on how to change the process-definition settings, see Process Definition Setting. For information on how to change the JVM settings, see Java virtual machine settings.
If the old resource that the generic server was managing is not installed under the old WebSphere Application Server installation, nothing further is required.
When migrating all WebSphere Application Server Version 6.1 or above EAR files to Version 8.5 using the wsadmin tool, the WASPostUpgrade tool uses the default maximum Java heap size value of 64 MB to install the EAR files.
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 WebSphere Application Server Version 8.5
wsadmin -conntype NONE
-c "$AdminApp install
C:\\WebSphere\\AppServer\\installableApps\\
EAR_file_name
{-nodeployejb
-appname app_name
-server server_name
-node node_name}"
Example of installing the application on WebSphere Application Server, Network Deployment Version 8.5
wsadmin -conntype NONE
-c "$AdminApp install
C:\\WebSphere\\ Manager\\installableApps\\
EAR_file_name>
{-nodeployejb
-appname app_name
-cluster cluster_name}"
You can migrate a WebSphere Application Server Version 6.1 or above node that belongs to a cell without removing the node from the cell.
Migrate the deployment manager first, before migrating any base nodes in the cell.
Migrating a base WebSphere Application Server node that is within a cell to Version 8.5 also migrates the node agent to Version 8.5. A cell can have some Version 8.5 nodes and other nodes that are at Version 6.1 or above levels. Read Coexistence support for information on restrictions on using mixed-release cells.
Migration copies files from prior version directories into the WebSphere Application Server Version 8.5 configuration.
WebSphere Application Server Version 8.5 migrates all the property files that are installed with Version 6.1 or above by merging settings into the Version 8.5 property files.
RARs that are referenced by J2C resources are migrated if those RARs are in the old WebSphere Application Server installation. In this case, the RARs are copied over to the corresponding location in the new WebSphere Application Server installation. Relational Resource Adapter RARs will not be migrated.
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172"
name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar">
...
</resources.j2c:J2CResourceAdapter>
If you 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 deployment manager, the tools migrate the cluster files on the deployment manager, including the resourcexxx.xml files.
In the migration of a federated node, the tools process each J2C adapter.
RAR files in a Version 6.1 to Version 8.5 migration:
Migration from Version 6.1 to Version 8.5 copies files such as RAR files from WAS_INSTALL_ROOT to WAS_INSTALL_ROOT and from USER_INSTALL_ROOT to USER_INSTALL_ROOT.
If you have a RAR file in the WAS_INSTALL_ROOT for Version 6.1, 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 Version 6.1, however, the Version 8.5 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.No migration of samples from previous versions is available. There are equivalent WebSphere Application Server Version 8.5 samples that you can install.
Java 2 security is enabled by default when you enable security in WebSphere Application Server Version 8.5. 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 Version 8.5. 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 Version 8.5 properties directory to enterprise applications
as they are being migrated.
For more information on migrating your security configurations to Version 8.5, read the "Migrating, coexisting, and interoperating – Security considerations" article in the information center.
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 WebSphere Application Server Version 8.5 installation
root.
The migration tools attempt to migrate existing passivation and working directories. Otherwise, appropriate Version 8.5 defaults are used.
The migration tools migrate all ports. You must resolve any port conflicts before you can run servers at the same time.
If you specify the -portBlock parameter in the WASPostUpgrade command, the specified 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, see Transport chains.
You must manually add virtual host alias entries for each port. For more information, see Configuring virtual hosts.
The specification level of the Java Platform, Enterprise Edition (Java EE) implemented in WebSphere Application Server Version 6.1 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.
If you migrate a Version 6.1 configuration that has feature packs installed, the migration tools might add one or two JVM system properties for each Java server in your 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 Version 8.5 default scan policy.