Diversas configurações são mapeadas durante a migração de configuração de produtos.
Muitos cenários de migração são possíveis. As ferramentas de migração mapeiam objetos e atributos existentes na versão a partir da qual você está migrando para objetos e atributos correspondentes no ambiente de versão mais nova.
As ferramentas de migração convertem parâmetros apropriados da linha de comandos para configurações da JVM (Java™ Virtual Machine) na definição do processo de servidor. A maioria das configurações é mapeada diretamente. Algumas configurações não são migradas, pois suas funções na configuração do WebSphere ESB versão 6.2 não existem, têm diferentes significados ou têm diferentes escopos.
Para obter informações sobre como alterar as configurações de definição de processo, consulte Configurações de Definição de Processo no centro de informações do WebSphere Application Server Network Deployment, versão 6.1. Para obter informações sobre como alterar as configurações da Java Virtual Machine, consulte Configurações de Java Virtual Machine no centro de informações do WebSphere Application Server Network Deployment, versão 6.1.
Ao migrar todos os arquivos EAR do WebSphere ESB para a versão 6.2 usando a ferramenta wsadmin, a ferramenta WBIPostUpgradeutiliza o valor máximo de tamanho de heap Java de 64 MB para instalar os arquivos EAR.
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError
Aumente o tamanho de heap Java máximo e siga o exemplo abaixo para instalar o aplicativo.
Exemplo de instalação de um aplicativo no WebSphere ESB versão 6.2
wsadmin -conntype NONE -javaoption -Xmx###m -c "$AdminApp install C:\\WebSphere\\ProcServer <EAR_file_name> {-nodeployejb -appname app_name -cluster cluster_name}"
Você pode migrar um nó do WebSphere ESB versão 6.0.x ou 6.1.x que pertence a uma célula no WebSphere ESB versão 6.2 sem remover o nó da célula.
Migre o gerenciador de implementação primeiro, antes de migrar qualquer nó base na célula.
Utilize o mesmo nome de célula ao migrar do versão 6.0.x ou 6.1.x para o versão 6.2 . Se você utilizar um nome de célula diferente, os nós federados não poderão ser migrados com sucesso para a célula do WebSphere ESB versão 6.2.
A migração para um nó base do WebSphere ESB que está em uma célula para a versão 6.2 também migra o agente do nó para a versão 6.2.
A migração copia arquivos de diretórios de versões anteriores para a configuração do WebSphere ESB versão 6.2.
O WebSphere migra todos os arquivos de propriedades que são instalados com o versão 6.0.x ou 6.1.x mesclando configurações nos arquivos de propriedades do versão 6.2.
A migração não sobrepõe arquivos de propriedades.
RARs e JARs que são referenciados por recursos J2C são migrados conforme a seguir:
Migrando recursos no nível do cluster
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar"> ... </resources.j2c:J2CResourceAdapter>
Se tiver um recurso no nível do cluster, esse recursos devem estar no mesmo local em cada membro do cluster (nó). Usando o exemplo acima, portanto, cada membro do cluster deve ter o arquivo RAR instalado no local ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} é resolvido em cada membro de cluster para obter o local exato.
Na migração de um gerenciador de implementação, as ferramentas migram os arquivos de cluster do gerenciador de implementação, incluindo os arquivos resourcexxx.xml.
Se tiver codificado permanentemente um caminho para um arquivo RAR (archivePath="C:/WAS/installedConnectors/x2.rar", por exemplo) na versão 6.0.x ou 6.1.x, no entanto, as ferramentas de migração da versão 6.2 não podem alterar o atributo archivePath para refletir isso, pois isso interromperia todos os outros membros do cluster que não foram migrados.
Durante a migração de um perfil independente, nenhuma amostra do WebSphere ESB é migrada. Amostras equivalentes do versão 6.2 estão disponíveis para todas as amostras do versão 6.2
A segurança Java 2 é ativada por padrão quando você ativa a segurança no WebSphere ESB versão 6.2. A segurança Java 2 requer que permissões de segurança sejam concedidas explicitamente.
Há diversas técnicas que podem ser utilizadas para definir diferentes níveis da segurança Java 2 na versão 6.2. Uma é criar um arquivo was.policy como parte do aplicativo para ativar todas as permissões de segurança. As ferramentas de migração chamam o comando wsadmin para incluir um arquivo was.policy existente no diretório properties da versão 6.2 para aplicativos corporativos à medida que estão sendo migrados.
Esse é o padrão.
Por exemplo, keyfiles e trustfiles existentes são movidos para fora do repertório SSLConfig e novos objetos keystore e truststore são criados.
Para manter as mesmas configurações de segurança, é necessário migrar as configurações de segurança do WebSphere Application Server que podem ter sido configuradas para a versão 6.0.2.x. Para obter informações adicionais sobre como migrar suas configurações de segurança para a versão 6.2, consulte Migrando, Coexistindo e Interoperando - Considerações sobre Segurança no centro de informações do WebSphere Application Server Network Deployment, versão 6.1.
O local desses diretórios está geralmente no diretório de instalação de uma versão anterior. O local padrão para stdin, stdout e stderr é o diretório logs da raiz de instalação do WebSphere ESB versão 6.2.
As ferramentas de migração tentam migrar para diretórios de passivação e de trabalho existentes. Caso contrário, os padrões apropriados da versão 6.2 são utilizados.
Para obter informações adicionais sobre os diretórios de passivação, consulte Configurações do Contêiner EJB. Para obter informações adicionais sobre diretórios de trabalho, consulte Configurações de Definição de Processo.
Em um cenário de coexistência, a utilização de diretórios comuns entre versões pode criar problemas.
As ferramentas de migração migram todas as portas. As ferramentas registram um aviso de conflito de porta se uma porta já estiver definida na configuração. Você deve resolver quaisquer conflitos de porta antes de poder executar servidores ao mesmo tempo.
Se o parâmetro -portBlock for especificado no comando WBIPostUpgrade, um novo valor é designado para cada transporte migrado.
Para obter informações adicionais sobre o comando WBIPostUpgrade, consulte Utilitário de Linha de Comandos WBIPostUpgrade.
Para obter informações adicionais sobre cadeias e canais de transporte, consulte Cadeias de Transporte.
Você deve incluir manualmente entradas de alias de host virtual para cada porta. Para obter informações adicionais, consulte Configurando Hosts Virtuais.
O nível de especificação do J2EE (Java 2 Platform, Enterprise Edition) implementado no WebSphere ESB versão 6.0.x ou 6.1.x necessitou de alterações de comportamento no contêiner de Web para configurar o tipo de conteúdo. Se um gravador de servlet padrão não configurar o tipo de conteúdo, não somente o contêiner da Web não o utiliza mais como padrão, como o contêiner de Web retorna a chamada como "nula". Essa situação pode fazer com que alguns navegadores exibam tags resultantes do contêiner de Web incorretamente. Para evitar a ocorrência desse problema, a migração define a extensão IBM® autoResponseEncoding para "true" para módulos da Web à medida que migra aplicativos corporativos.