Configuration mapping during product-configuration migration

Various configurations are mapped during product-configuration migration.

Configurações suportadas Configurações suportadas:

Este artigo trata da migração da configuração de perfil. Para migrar seus aplicativos para a versão mais recente, use o Kit de Ferramentas de Migração do WebSphere® Application Server. Para obter mais informações, consulte o Kit de ferramentas de migração no WASdev.

sptcfg

Migration always involves migrating a single profile to another single profile on the same IBM i server. The migration tools map objects and attributes existing in the version or WebSphere Application Server from which you are migrating to the corresponding objects and attributes in the Versão 9.0 environment.

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 Versão 9.0 environment.

Bootstrap port

The migration tools carry the old release value into the Versão 9.0 environment.

If the -setPorts parameter is set to generateNew or a port value during the call to WASPostUpgrade, however, the port value is given to each application server that is migrated to Versão 9.0.

Command-line parameters

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 Versão 9.0 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.

Generic server
In Versão 7.0 ou posterior, 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 WebSphere Application Server installation, perform the following tasks:
  1. Copy any related files to the new installation.
  2. Run any setup required to put the external application back into a valid and working state.

    It is best that you reinstall the resource into the new WebSphere Application Server directory. Whatever you choose to do, the final step is to reset the reference to the new location of the application.

If the old resource that the generic server was managing is not installed under the old WebSphere Application Server installation, nothing further is required.

Migration of a Versão 7.0 ou posterior node to a Versão 9.0 node

You can migrate a WebSphere Application Server Versão 7.0 ou posterior 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.

Important: Use the same cell name when migrating WebSphere Application Server, Network Deployment from Versão 7.0 ou posterior to Versão 9.0. If you use a different cell name, federated nodes cannot successfully migrate to the WebSphere Application Server, Network Deployment Versão 9.0 cell.

Migrating a base WebSphere Application Server node that is within a cell to Versão 9.0 also migrates the node agent to Versão 9.0. A cell can have some Versão 9.0 nodes and other nodes that are at Versão 7.0 ou posterior levels.

Policy files
WebSphere Application Server Versão 9.0 migrates all the policy files that are installed with Versão 7.0 ou posterior by merging settings into the Versão 9.0 policy files with the following characteristics:
  • Any comments located in the Versão 9.0 policy files will be preserved. Any comments contained in the Versão 7.0 ou posterior policy files will not be included in the Versão 9.0 file.
  • Migration will not attempt to merge permissions or grants; it is strictly an add-type migration. If the permission or grant is not located in the Versão 9.0 file, the migration will bring it over.
  • Security is a critical component; thus, the migration makes any additions at the end of the original .policy files right after the comment MIGR0372I: Migrated grant permissions follow. This is done to help administrators verify any policy-file changes that the migration has made.
Properties and classes directories

Migration copies files from prior version directories into the WebSphere Application Server Versão 9.0 configuration.

Property files

WebSphere Application Server Versão 9.0 migrates all the property files that are installed with Versão 7.0 ou posterior by merging settings into the Versão 9.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 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.

Migrating cluster-level resources:
WebSphere Application Server Version 6.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 you have a cluster-level resource, this resource must be in the same location on each cluster member (node). Using the previous 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 7.0 to Versão 9.0 migration:

Migration from Version 7.0 to Versão 9.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 you have a RAR file in the WAS_INSTALL_ROOT for Version 7.0, 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 7.0, however, the Versão 9.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 WebSphere Application Server Versão 9.0 samples that you can install.

Security

Java 2 security is enabled by default when you enable security in WebSphere Application Server Versão 9.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 Versão 9.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 Versão 9.0 properties directory to enterprise applications as they are being migrated.

When migrating to WebSphere Application Server Versão 9.0, your choice of whether or not to migrate to support script compatibility results in one of two different outcomes.
  • If you choose to migrate to support script compatibility, your security configuration is brought over to Versão 9.0 without any changes.

    This is the default.

  • If you choose not to migrate to support script compatibility, the security configuration is converted to the default configuration for WebSphere Application Server Versão 9.0. The default security configuration for Versão 7.0 ou posterior acts almost the same as in the previous versions, but there are some changes.

    For example, existing keyfiles and trustfiles are moved out of the SSLConfig repertoire and new keystore and truststore objects are created.

For more information on migrating your security configurations to Versão 9.0, read the "Migrating, coexisting, and interoperating – Security considerations" article in the documentation.

Stdin, stdout, stderr, passivation, and working directories

The location for these directories is typically the logs directory under the WebSphere Application Server profile directory. For WebSphere Application Server Versão 9.0, the default location for the stdin, stdout, and stderr files is the logs directory located under the WebSphere Application Server profile directory—for example, the logs directory for the default profile is /QIBM/UserData/WebSphere/AppServer/V80/Base/profiles/default/logs.

The migration tools attempt to migrate existing passivation and working directories. Otherwise, appropriate Versão 9.0 defaults are used.

Evitar Problemas Evitar Problemas: In a coexistence scenario, using common directories between versions can create problems.gotcha
Web modules

The specification level of the Java Platform, Enterprise Edition (Java EE) implemented in WebSphere Application Server Version 7.0 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.


Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: June 20, 2016 0:07
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-iseries&topic=cmig_configmap
Nome do arquivo: cmig_configmap.html