Various configurations are mapped during product-configuration migration.
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 newer version's environment.
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 ESB version 6.2 configuration do not exist, have different meanings, or have different scopes.
For information on how to change the process-definition settings, see Process definition settings in the WebSphere Application Server Network Deployment, version 6.1 information center. For information on how to change the Java virtual machine settings, see Java virtual machine settings in the WebSphere Application Server Network Deployment, version 6.1 information center.
When migrating all WebSphere ESB EAR files to version 6.2 using the wsadmin tool, the WBIPostUpgrade 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 an application on WebSphere ESB version 6.2
wsadmin -conntype NONE -javaoption -Xmx###m -c "$AdminApp install C:\\WebSphere\\ProcServer <EAR_file_name> {-nodeployejb -appname app_name -cluster cluster_name}"
You can migrate a WebSphere ESB version 6.0.x or 6.1.x node that belongs to a cell to WebSphere ESB version 6.2 without removing the node from the cell.
Migrate the deployment manager first, before migrating any base nodes in the cell.
Use the same cell name when migrating from version 6.0.x or 6.1.x to version 6.2. If you use a different cell name, federated nodes cannot successfully migrate to the WebSphere ESB version 6.2 cell.
Migrating a base WebSphere ESB node that is within a cell to version 6.2 also migrates the node agent to version 6.2.
Migration copies files from prior version directories into the WebSphere ESB version 6.2 configuration.
WebSphere migrates all the property files that are installed with version 6.0.x or 6.1.x by merging settings into the version 6.2 property files.
Migration does not overlay property files.
RARs and JARs that are referenced by J2C resources are migrated as follows:
Migrating cluster-level resources
<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.
If you hardcoded a path to a RAR file (archivePath="C:/WAS/installedConnectors/x2.rar" for example) in version 6.0.x or 6.1.x, however, the version 6.2 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.
During migration of a stand-alone profile, no WebSphere ESB samples are migrated. Equivalent version 6.2 samples are available for all version 6.2 samples
Java 2 security is enabled by default when you enable security in WebSphere ESB version 6.2. 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 6.2. 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 6.2 properties directory to enterprise applications as they are being migrated.
This is the default.
For example, existing keyfiles and trustfiles are moved out of the SSLConfig repertoire and new keystore and truststore objects are created.
In order to retain the same security settings, you need to migrate the WebSphere Application Server security settings that might have been set for version 6.0.2.x. For more information on migrating your security configurations to version 6.2, see Migrating, coexisting, and interoperating - Security considerations in the WebSphere Application Server Network Deployment, version 6.1 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 ESB version 6.2 installation root.
The migration tools attempt to migrate existing passivation and working directories. Otherwise, appropriate version 6.2 defaults are used.
For more information on passivation directories, see EJB container settings. For more information on working directories, see Process definition settings.
In a coexistence scenario, using common directories between versions can create problems.
The migration tools migrate all ports. The tools log a port-conflict warning if a port is already defined in the configuration. You must resolve any port conflicts before you can run servers at the same time.
If the -portBlock parameter is specified in the WBIPostUpgrade command, a new value is assigned to each transport that is migrated.
For more information on the WBIPostUpgrade command, see WBIPostUpgrade command-line utility.
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 2 Platform, Enterprise Edition (J2EE) implemented in WebSphere ESB version 6.0.x or 6.1.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.