Migrando do WebSphere Studio "Classic" para o IBM WebSphere
Studio Site Developer
Capítulo 1. Visão Geral do Guia de Migração do WebSphere Application Server - Express
Capítulo 2. Migrando o Servidor de Produção
Capítulo 3. Migrando do IBM WebSphere Studio Site Developer Versão 5.1
Capítulo 4. Migrando do IBM WebSphere Studio Site Developer Versão 5 ou Versão 5.0.1
Capítulo 5. Migrando do IBM WebSphere Studio Site Developer Versão 4.0.x
Capítulo 6. Migrando do WebSphere Studio "Classic" para o IBM WebSphere Studio Site Developer
Capítulo 7. Migrando do VisualAge para Java para o IBM WebSphere Studio Site Developer
Capítulo 8. Migrando do VisualAge para Java Visual Composition Editor para o Visual Editor para Java
Capítulo 10. Exemplos de Migração
Capítulo 11. Leitura Adicional
Nesta versão do IBM(R) WebSphere(R)Application Server - Express Versão 5.1, é possível migrar o código a partir do:
O WebSphere Application Server - Express 5.1 é formado pelo WebSphere Application Server 5.1 e pelo WebSphere Studio Site Developer 5.1.1. Esse primeiro capítulo a seguir, aborda a migração do recurso do servidor do WebSphere Application Server - Express. O restante desse Guia de Migração é destinado à migração do código de diferentes versões do WebSphere Studio Site Developer.
Nota Importante a Respeito da Migração do Servidor:
A migração da configuração do servidor apenas é significativa, se você estiver administrando o servidor utilizando o Administrative Console -- normalmente, em um ambiente de produção. Nesse modo de operação, a configuração do servidor e os aplicativos implementados são armazenados no diretório de configuração do servidor. O processo de migração migra esses arquivos de configuração e de aplicativo. Se, por outro lado, você estiver utilizando o WebSphere Studio Site Developer para configurar e implementar aplicativos no servidor remoto, não há necessidade de migrar os arquivos de configuração do servidor. Isso acontece porque os arquivos de configuração e de aplicativo são todos mantidos no espaço de trabalho do Studio Site Developer. O espaço de trabalho será migrado pelo Studio Site Developer. Em seguida, você pode definir uma nova instância de um servidor do WebSphere Application Server - Express 5.1 e continuar a configuração e implementação dos aplicativos a partir do Studio Site Developer.
Este guia está organizado nos seguintes capítulos:
Migrando do WebSphere Studio "Classic" para o IBM WebSphere
Studio Site Developer
Informações sobre como utilizar o WebSphere Application Server - Express podem ser localizadas no guia Introdução e na ajuda on-line. Leia o Guia de Instalação antes de instalar o WebSphere Application Server - Express. Depois de instalar com êxito o WebSphere Application Server - Express, leia o guia Introdução e execute os tutoriais de Introdução. Os tutoriais o apresentarão ao workbench, ao desenvolvimento Java(TM) e aos serviços da Web. Após a conclusão dos tutoriais, leia este guia para migrar os recursos do aplicativo para o WebSphere Application Server - Express.
Esse guia está disponível nas versões HTML e Acrobat PDF, no diretório /readme. Ambas as versões contêm informações idênticas. Você pode abrir o arquivo migrate.html em qualquer navegador da Web. Para abrir o arquivo migrate.pdf, você deve ter o software Acrobat Reader instalado, o qual pode ser transferido por download a partir do endereço www.adobe.com/products/acrobat/readstep2.html.
Este Guia de Migração utiliza as convenções do Windows(R) em todo o processo. Por exemplo, o "WS_Installdir\" no Windows é equivalente ao "WS_Installdir/" no Linux.
Para obter atualizações futuras deste guia, consulte www.ibm.com/websphere/developer/zones/studio/transition.html.
Migração é uma atividade na qual você se beneficia de materiais existentes. As tarefas e ferramentas de migração ajudam no upgrade do produto e de seus pré-requisitos, na reutilização de componentes do aplicativo existente quando possível e na transferência de configurações administrativas de sua versão anterior para uma atual.
A migração de produtos do WebSphere Application Server é relativa a alavancar o ambiente e aplicativos existentes e alterá-los para que sejam compatíveis com a versão do produto atual.
As funções de migração do produto são fornecidas pelas ferramentas de migração no IBM WebSphere Application Server - Express, Versão 5.1. As ferramentas de migração suportam a migração do:
O assistente para instalação do produto detectará versões anteriores do IBM WebSphere Application Server - Express e fornecerá uma opção para executar as ferramentas de migração durante a instalação da Versão 5.1. Para migrar do IBM WebSphere Application Server Versão 3.5, é necessário executar essas ferramentas diretamente.
Redbook de Migração
Migrating to WebSphere V5: An End-to-End Migration Guide está disponível a partir do Web site de Redbooks no endereço http://www.ibm.com/redbooks. Para localizar o Redbook, procure o número do documento SG24-6910-00. O Redbook fornece uma cobertura maior que esse artigo, incluindo informações sobre planejamento com detalhes adicionais para migração de aplicativo e ferramentas e amostras do WebSphere Studio Application Developer.
Migração da Versão 3.5: Movendo para o Modelo J2EE
Os usuários da V3.5.x fazendo upgrade para V5 estão movendo para uma plataforma que é baseada nas especificações J2EE. A tecnologia J2EE separa claramente o desenvolvimento e a criação de aplicativos da administração, implementação e gerenciamento do aplicativo. A migração da V3.5 envolve alterações nas estruturas, desenvolvimento e implementação de aplicativos.
As ferramentas de migração ajudam na transição da Versão 3.5.x para a Versão 5, através da migração de configurações do sistema e da criação de artefatos J2EE, incluindo o mapeamento de funções de segurança J2EE. As ferramentas de migração criam aplicativos corporativos J2EE iniciais com base nas configurações da Versão 3.5.x. No entanto, devido à alteração significativa em estruturas de aplicativos, planeje cuidadosamente o teste e o ajuste dos aplicativos migrados, utilizando as ferramentas de desenvolvimento e de implementação, para determinar exatamente como os aplicativos funcionam no novo ambiente.
O modelo J2EE permite o desenvolvimento de aplicativos independentemente do ambiente de implementação final. Essa separação de tarefa simplifica o processo de promover um aplicativo do desenvolvimento inicial através da produção, ou de movimento de um aplicativo de um servidor para outro. A intenção é alterar apenas os parâmetros de implementação de aplicativo e não o código do aplicativo.
Antes de iniciar, determine se você tem uma versão existente do WebSphere Application Server instalada na máquina em que planeja instalar o produto Versão 5.1. Se você tiver uma versão anterior, será necessário planejar se pretende copiar a configuração e aplicativos da versão anterior para a versão nova, que é a migração. A migração não desinstala a versão anterior. O release anterior ainda é funcional. Se você executá-lo ao mesmo tempo que a instalação da Versão 5.1, as duas versões serão coexistentes. Para executar ambas as versões ao mesmo tempo, você precisará configurar as portas de modo que elas não entrem em conflito. Observe que a operação de migração apenas migra as definições de porta no estado em que se encontram, a fim de que as definições sejam as mesmas em ambas as versões. O WebSphere Application Server contém ferramentas de migração que fornecem toda funcionalidade de migração. O assistente para instalação pode chamar as ferramentas de migração ou você pode chamá-las manualmente mais tarde.
Em resumo, a migração do IBM WebSphere Application Server - Express V5.0.x para V5.1 é rotina habitual. É possível utilizar o instalador para migrar e ter um pouco ou nenhum ajuste de migração posterior a ser desempenhado. Ou você pode utilizar as ferramentas de migração manualmente para salvar os dados de configuração V5.0.0, V5.0.1 ou V5.0.2, desinstalar a V5.0.0, V5.0.1 ou V5.0.2, instalar a V5.1 e utilizar as ferramentas de migração novamente para restaurar os dados de configuração.
Em resumo, a migração do IBM WebSphere Application Server V3.5 para IBM WebSphere Application Server - Express V5.1 envolve alterações significativas em estruturas, desenvolvimento e implementação de aplicativo. As ferramentas de migração ajudam nessa transição através da migração de configurações do sistema e da criação de artefatos J2EE, incluindo o mapeamento de definições de segurança anteriores para funções de segurança J2EE. Esses mapeamentos de segurança permitem o acesso a recursos migrados durante a transição. As ferramentas de migração criam aplicativos corporativos J2EE iniciais com base nas configurações da Versão 3.5.x. No entanto, devido as alterações significativas nas estruturas do aplicativo, teste e ajuste com cuidado os aplicativos migrados utilizando as ferramentas de desenvolvimento e de implementação.
A migração salva os arquivos a seguir no diretório backup.
Esse tópico apresenta as ferramentas de migração que o WebSphere Application Server fornece. Todas as ferramentas de migração são enviadas para o diretório /migration no CD-ROM do produto. É importante utilizar essas ferramentas para a versão do Application Server que está sendo instalada. Elas são alteradas o tempo todo. As ferramentas no CD-ROM do produto fornecem a função necessária para migração de um release anterior do Application Server para o release no CD-ROM do produto. As que se encontram no CD-ROM correspondem ao produto no CD-ROM. Se você utilizar as ferramentas de migração de um release anterior do Application Server, provavelmente encontrará um problema com a migração.
O script WASPreUpgrade.sh (ou WASPreUpgrade.bat) é uma ferramenta de migração para migração da configuração e de aplicativos de versões ou releases anteriores para um Application Server - Express Versão 5.1.
O arquivo de comandos está localizado no subdiretório AppServer/bin da raiz de instalação após a instalação. Ele também está disponível diretamente a partir do CD no subdiretório migration.
Sintaxe
WASPreUpgrade backupDirectory currentWASDirectory
[adminNodeName]
[-nameServiceHost host_name [-nameServicePort port_number ]]
[-traceString trace_spec [-traceFile file_name ]]
Parâmetros
Os primeiros dois argumentos são necessários e posicionais.
Os argumentos suportados incluem:
Registro
A ferramenta WASPostUpgrade exibe o status para a tela enquanto está sendo executada. Ela também salva um conjunto de informações sobre registro mais amplo no diretório backup. Você pode exibir o arquivo WASPreUpgrade.log com um editor de texto.
O script WASPostUpgrade.sh (ou WASPostUpgrade.bat) é uma ferramenta de migração para migração da configuração e de aplicativos de versões ou releases anteriores para um Application Server - Express Versão 5.1.
O arquivo de comandos está localizado no diretório AppServer/bin da raiz de instalação.
A ferramenta WASPostUpgrade instala todos os aplicativos migrados no diretório AppServer/installedApps para a instalação da Versão 5.1. A ferramenta inclui aplicativos do diretório de backup que a ferramenta WASPreUpgrade cria. A ferramenta WASPreUpgrade copia os aplicativos do diretório installedApps e outros diretórios na versão ou release anterior.
Sintaxe
WASPostUpgrade backupDirectory
[-serverName server_name]
[-webModuleAdditionalClasspath classpath]
[-documentRootLimit number]
[-substitute "key1=value1[;key2=value2;[...]]"]
[-portBlock port_starting_number]
[-backupConfig true | false]
[-replacePorts true | false]
[[-traceString trace_spec [-traceFile file_name]]
Parâmetros
O primeiro argumento é necessário. Os argumentos suportados incluem:
No arquivo de dados XML de entrada, cada chave aparece como $key$ para substituição. Esse argumento substitui qualquer ocorrência de $NODE_NAME$ por admin_node e $APP_SERVER$ por default_server no arquivo XML de entrada.
Se a cadeia de substituição contiver pontos-e-vírgulas, utilize $semiColon$ para separá-la do delimitador ";". Em plataformas UNIX, adicione um caractere de escape a cada cifrão ($) na cadeia de substituição (por exemplo, \$semiColon\$).
Esse parâmetro é aplicável para configurações salvas do Advanced Edition, Versão 3.5.x.
Registro
A ferramenta WASPostUpgrade exibe o status para a tela enquanto está sendo executada. Ela também salva um conjunto de informações sobre registro mais amplo no diretório logs. Você pode exibir o arquivo WASPostUpgrade.log com um editor de texto.
Esse tópico descreve o que é alterado durante a migração, que sempre envolve uma única máquina, como por exemplo um ambiente de desenvolvimento em uma máquina independente.
Analise o arquivo WASPostUpgrade.log para obter informações detalhadas sobre os beans corporativos migrados. O modelo de programação J2EE especifica uma arquitetura sobre como os aplicativos são criados e implementados. Como os aplicativos na Versão 3.5.x não têm a mesma arquitetura, a ferramenta WASPostUpgrade recria os aplicativos. Ela cria todos os recursos e os beans corporativos da Web migrados em aplicativos J2EE. Ela mapeia todos os aplicativos corporativos da instalação da Versão 3.5.x em aplicativos J2EE com o mesmo nome, implementados no mesmo servidor.
A ferramenta WASPostUpgrade mapeia recursos da Web que estão incluídos em um aplicativo corporativo, em um aplicativo J2EE padrão que inclui o nome do servidor. A ferramenta mapeia aplicativos da Web para arquivos WAR J2EE. Ela combina recursos em um arquivo WAR J2EE e os implementa na configuração da Versão 5.
Você pode utilizar um arquivo datasources.xml da Versão 3.5.x para aumentar as definições de configuração do DataSource. A Versão 3.5.x armazena o arquivo no diretório properties. As ferramentas de migração migram um arquivo datasources.xml existente, combinando as propriedades no arquivo na configuração do datasource e do driver JDBC.
As entradas do aplicativo corporativo Versão 3.5.x são opcionais, elas são mais freqüentemente utilizadas para organizar conjuntos de objetos juntos para definições de Segurança. O bean corporativo e as partes de aplicativos da Web do aplicativo corporativo apontam para suas respectivas entradas em outras partes do arquivo xml. Cada aplicativo corporativo é processado para criar um aplicativo J2EE com o mesmo nome. As entradas do bean corporativo e de aplicativos da Web são utilizadas como ponteiros para as definições de beans corporativos e de aplicativos da Web. Os detalhes dessas entradas são utilizados, em seguida, para construir um aplicativo J2EE.
Para arquivos do bean corporativo, a definição de arquivo JAR é utilizada para localizar os arquivos JAR para reimplementar e adicionar ao aplicativo J2EE. As entradas raiz de documentos de aplicativos da Web são utilizadas para localizar os recursos utilizados no aplicativo da Web (HTML, páginas JSP e assim por diante). Esses arquivos são copiados para o arquivo WAR dentro do aplicativo J2EE. As entradas de classpath de aplicativos da Web são utilizadas para localizar servlets e arquivos JAR copiados para o arquivo WAR no aplicativo J2EE.
Os aplicativos corporativos são criados durante a migração da Versão 3.5.x. Esses são criados como aplicativos corporativos compatíveis com J2EE 1.2 e contêm os módulos de nível do Servlet 2.2 e JSP 1.1. Isso fornece a compatibilidade direta e permite a interoperabilidade com versões anteriores do WebSphere Application Server.
O modelo de autorização de segurança na versão 3.5.x é baseado na noção de Aplicativo Corporativo e Grupos de Métodos. O produto cruzado do aplicativo corporativo e os grupos de métodos representa uma permissão do WebSphere Application Server. A especificação J2EE inclui um modelo de autorização com base em funções.
Para converter do modelo de permissão do WebSphere Application Server na versão 3.5.x para a função com base no modelo de autorização na Versão 5, as ferramentas de migração criam uma relação um para um de uma permissão do WebSphere Application Server para uma nova função desse aplicativo. Portanto, para cada aplicativo corporativo e cada grupo de métodos na Versão 3.5.x, as ferramentas de migração criam uma função na Versão 5, contida no descritor de implementação de aplicativo J2EE. Os assuntos autorizados para cada função estão contidos em uma tabela de autorização localizada na ligação de aplicativo J2EE.
A especificação J2EE inclui um modelo de autorização com base em funções. O WebSphere Application Server interpreta a função para significar um conjunto de permissões de acesso a um recurso. No caso de uma chamada de método do bean corporativo, a permissão de acesso ao método em um bean específico é especificada pela permissão a um método. Essa permissão de método é associada a uma ou mais funções no descritor de implementação no arquivo JAR do bean.
No caso de acesso a recursos da Web, a permissão de acesso a uma URI da Web e de chamada a um método HTTP nessa URI é especificada em termos de coletas de recursos da Web e limitações de segurança na especificação J2EE. O descritor de implementação do arquivo WAR de aplicativos da Web contém as limitações de segurança e coletas de recursos da Web.
A Versão 5 executa objetos JSP 1.0 e 1.1 como objetos JSP 1.2, que é o único nível suportado.
A Versão 5 não suporta o Redirecionador de Servlet de versões anteriores. As ferramentas de migração ignoram esses objetos.
Se a configuração da Versão 3.5.x definir o servlet SimpleFileServlet, o servlet não será migrado. As ferramentas de migração definem o atributo FileServingEnabled no arquivo de módulo da Webibm-web-ext.xmi como true.
Se a configuração da Versão 3.5 definir o servlet InvokerServlet, o servlet não será migrado. As ferramentas de migração definem o atributo ServeServletsByClassnameEnabled no arquivo de módulo da Wev ibm-web-ext.xmi como true.
Se a configuração da Versão 3.5.x definir o servlet DefaultErrorReporter, o servlet não será migrado no arquivo de módulo da Web web.xml. A migração utiliza o novo pacote para definir o nome da classe.
O tipo de transporte padrão do Servlet Engine na Versão 3.5.x é OSE (Open Servlet Engine). Como a Versão 5 não mais suporta o transporte OSE, as ferramentas de migração mapeiam esses transportes para transportes HTTP, utilizando as mesmas atribuições de porta. Você deve adicionar manualmente as entradas do alias VirtualHost para cada porta.
Você pode migrar as configurações administrativas com o assistente para instalação ou manualmente, como essa tarefa descreve. Se decidir migrar manualmente, não selecione a caixa de opções migration no painel installation wizard migration.
Se você utilizar uma versão anterior do WebSphere Application Server, o administrador do sistema pode ter vários aplicativos bem ajustados e definições do servidor para seu ambiente. É importante ter uma estratégia para migração dessas definições com o máximo de eficiência e o mínimo de perda.
É possível desempenhar várias vezes a migração manual incremental pela chamada das ferramentas de migração, toda vez que especificar um arquivo de configuração diferente. Há diversos motivos para a existência de múltiplos arquivos de configuração. Seja qual for o motivo, a migração de um arquivo de configuração por vez permite que aplicativos sejam testados incrementalmente, antes de continuar com o próximo arquivo de configuração.
Antes de utilizar as ferramentas de migração, consulte o documento Notas sobre o Release V5.x para entender quais correções são necessárias aplicar em versões anteriores. A aplicação de correções em uma versão anterior também pode aplicar correções em arquivos que têm uma função na migração. Aplique quaisquer correções para garantir a migração mais eficiente de configurações e aplicativos possíveis.
A migração manual fornece uma abordagem de migração mais incremental do que a migração completa fornecida pelo assistente para instalação. A IBM fornece um conjunto de ferramentas de migração para migrar configurações administrativas para o produto WebSphere Application Server - Express de qualquer edição da V3.5.x ou V5.0.x. O processo de migração total serve para fazer backup da configuração atual e de arquivos necessários com a ferramenta de migração WASPreUpgrade, desinstalar o release anterior, instalar o produto Versão 5 sem selecionar a opção de migração automática e restaurar a configuração do release anterior com a ferramenta de migração WASPostUpgrade.
Selecione qualquer um desses cenários de migração, para obter informações sobre como migrar dados de configuração para um nó de base do WebSphere Application Server:
É possível utilizar as ferramentas de migração para migrar dados de configuração da Versão 3.5 do WebSphere Application Server para a Versão 5.1 do WebSphere Application Server - Express.
Normalmente, você utilizaria as ferramentas de migração WASPreUpgrade e WASPostUpgrade da V5.1 do WebSphere Application Server para fazer upgrade da V3.5 para a V5.1 na mesma máquina. Se o cenário incluir a migração de uma configuração da V3.5 em uma máquina para o WebSphere Application Server - Express V5.1 em outra máquina, utilize o procedimento alternativo descrito em Migrando a V3.5.x para uma Máquina V5.1 Remota.
Esse tópico descreve o uso de ferramentas de migração V5.1 a serem migradas:
A ferramenta WASPreUpgrade salva a configuração da V3.5 existente em um diretório de migration-specific-backup. A ferramenta WASPostUpgrade utiliza esse diretório para adicionar as definições de configuração antigas ao novo ambiente V5.1.
Etapas para Esta Tarefa
Nesse CD encontra-se o diretório migration/bin. Esse diretório contém um ambiente especial que você pode utilizar para executar a ferramenta WASPreUpgrade sem instalar a V5.1.
Salve a configuração no diretório migration-specific-backup:
WASPreUpgrade /usr/tmp/migration-specific-backup /usr/websphere/appserver yourNodeName
Verifique se o servidor administrativo do ambiente existente está sendo executado. A ferramenta WASPreUpgrade fornece o status para a tela e para arquivos do log no diretório migration-specific-backup. Os nomes de arquivos de logs ASCII começam com a ferramenta WASPreUpgrade de texto e incluem uma data e hora.
A ferramenta WASPreUpgrade salva todos os arquivos dos diretórios a seguir na configuração V3.5.x existente no diretório de backup:
A ferramenta WASPreUpgrade salva os arquivos selecionados do diretório /bin V3.5.x. Ela também exporta a configuração do Application Server existente do repositório V3.5.x. Essa ferramenta chama a XMLConfig para exportar o repositório V3.5 existente para o arquivo websphere_backup.xml no diretório migration-specific-backup.
Se ocorrem erros durante a execução da ferramenta WASPreUpgrade, pode ser preciso aplicar correções à instalação da V3.5 para concluir com êxito a etapa de exportação. Consulte a página IBM Support para obter as correções mais recentes possíveis de serem aplicadas. Na exibição dessas informações do InfoCenter, clique em Support para efetuar o link com a página IBM Support.
Não selecione a opção de migração, se ela aparecer.
Após cada uso da ferramenta WASPostUpgrade, verifique as definições de porta da V5 em dois arquivos:
Se a porta BOOTSTRAP_ADDRESS da versão anterior for 900, a migração mapeia isso para 7809. Se a porta BOOTSTRAP_ADDRESS da versão anterior não for 900, a migração mapeia o valor para server1 em uma migração Advanced Edition ou para o nome do servidor real em uma migração Advanced Single Server Edition.
O processamento de WASPostUpgrade adiciona as portas HTTP Transport da versão anterior no arquivo server.xml da Versão 5. Isso significa que o server1 contém atribuições duplicadas da porta HTTP Transport, a partir do painel de coexistência e da versão anterior do Servidor Padrão.
A ferramenta WASPostUpgrade migra as informações de configuração da V3.5.x criadas pela ferramenta WASPreUpgrade para a instalação da V5.1. Como o produto V5.1 adere ao modelo de programação J2EE e o produto V3.5.x não adere, as alterações significativas são necessárias para aplicação da configuração da V3.5.x em uma instalação da V5.1.
A ferramenta WASPostUpgrade não migra Amostras ou o aplicativo de console administrativo, pois já há Amostras e um aplicativo do console administrativo na V5.1.
A ferramenta WASPostUpgrade registra informações detalhadas em cada bean corporativo implementado, no arquivo WASPostUpgrade.log.
A configuração do WebSphere Application Server após a migração é uma forma de verificar os resultados das ferramentas de migração. É possível também utilizar o mapeamento de Configuração durante a migração, para verificar os resultados da migração. O tópico possui uma descrição detalhada de como as ferramentas de migração migram objetos e o que você deve verificar.
Você pode utilizar as ferramentas de migração para desempenhar uma migração manual entre duas máquinas.
Normalmente, você utilizaria as ferramentas de migração WASPreUpgrade e WASPostUpgrade da V5.1 do WebSphere Application Server - Express para fazer upgrade da V3.5 para a V5.1 na mesma máquina.
No entanto, há alguns cenários onde você deve migrar a configuração da V3.5 em uma máquina para a V5.1 em uma máquina diferente. Um desses cenários é a instalação de novas máquinas no ambiente da V5.1 mais recente, mas há necessidade de migrar a configuração da V3.5 existente em outras máquinas.
Esse tópico descreve o uso de ferramentas de migração V5.1 a serem migradas:
A ferramenta WASPreUpgrade salva a configuração da V3.5 existente em um diretório de migration-specific-backup. A ferramenta WASPostUpgrade utiliza esse diretório para adicionar as definições de configuração antigas ao novo ambiente V5.1.
Etapas para Esta Tarefa
Nesse CD encontra-se o diretório migration/bin. Esse diretório contém um ambiente especial que você pode utilizar para executar a ferramenta WASPreUpgrade sem instalar a V5.1.
Salve a configuração no diretório migration-specific-backup na máquina V3.5.
WASPreUpgrade /opt/tmp/migration-specific-backup /opt/websphere/appserver adminNodeName
Verifique se o servidor administrativo do ambiente existente está sendo executado.
A ferramenta WASPreUpgrade fornece o status para a tela e para arquivos do log no diretório /migration-specific-backup. Os nomes de arquivos de logs ASCII começam com a ferramenta WASPreUpgrade de texto e incluem uma data e hora.
A ferramenta WASPreUpgrade salva os arquivos selecionados do diretório /bin V3.5.x. Ela também exporta a configuração do Application Server existente do repositório V3.5.x. Essa ferramenta chama a XMLConfig para exportar o repositório V3.5 existente para o arquivo websphere_backup.xml no diretório migration-specific-backup.
Se ocorrem erros durante a execução da ferramenta WASPreUpgrade, pode ser preciso aplicar correções à instalação da V3.5 para concluir com êxito a etapa de exportação. Consulte a página IBM Support para obter as correções mais recentes possíveis de serem aplicadas. Na exibição dessas informações do InfoCenter, clique em Support para efetuar o link com a página IBM Support.
Utilize o ftp, o armazenamento compartilhado ou algum outro mecanismo para copiar o arquivo para a nova máquina.
Desempenhe as etapas a seguir na máquina com a V5.1 do WebSphere Application Server - Express..
Você está copiando o arquivo porque o arquivo original será editado na próxima etapa.
Faça essas alterações no arquivo:
Se você estiver utilizando o mesmo nome do nó para a máquina V5.1 utilizada para a configuração da V3.5 original, não altere o nome. Do contrário, você deve alterar todas as ocorrências do nome do nó da V3.5 para o nome do nó sendo utilizado para o WebSphere Application Server V5.1. O nome do nó ocorre em muitas sub-rotinas XML por todo o arquivo. A falha na alteração de todas as ocorrências resulta em uma migração incompleta de dados.
O arquivo de configuração refere-se a nomes de caminhos em muitas sub-rotinas XML por todo o arquivo. Atualize qualquer referência a um arquivo fora da estrutura de diretórios V3.5 para o diretório equivalente na nova máquina, mesmo se for necessário criar um diretório equivalente. A implicação de configuração de um ambiente correspondente significa que pode ser preciso copiar o diretório original para a máquina V5.1. Ou pode ser preciso instalar o software apropriado.
É necessário corrigir as especificações de caminho, se elas diferirem daquelas que funcionam na máquina que está executando a V5.1. Por exemplo, se você estiver mudando da V3.5 em uma plataforma Windows para a V5.1 em uma plataforma Linux, altere qualquer caminho específico do Windows no arquivo de configuração, para utilizar o estilo de caminho do Linux. Mude de "c:\mystuff\somepath" para "/opt/mystuff/somepath".
Pode ser preciso alterar os IDs de usuários e senhas, se eles não forem idênticos àqueles em uso na máquina V5.1.
Para alterar uma senha codificada para uma senha de texto limpo, mude <password>{xor}LCoxayht</password> para <password>mypassword</password>.
A configuração pode se referir a outros produtos ou configurações de software que não existem na nova máquina. Por exemplo, a máquina antiga pode ter um banco de dados. Possivelmente, a configuração da V5.1 ainda deve apontar para o banco de dados na máquina antiga. Modifique o datasource para apontar para o banco de dados na máquina V3.5.
Utilize a ferramenta WASPostUpgrade no diretório AppServer/bin do diretório raiz de instalação da V5.1, para adicionar a configuração da V3.5 à configuração da V5.1.
WASPostUpgrade /opt/tmp/migration-specific-backup
A ferramenta WASPostUpgrade registra informações detalhadas específicas a cada bean corporativo implementado, no arquivo /migration-specific-backup/WASPostUpgrade.log.
Você pode utilizar o programa de instalação da V5.1 para migrar do WebSphere Application Server - Express V5.0.x para V5.1.
Etapas para esta tarefa:
Utilize o script stopServer.sh (ou stopServer.bat) do diretório AppServer/bin da raiz de instalação:
stopServer.sh server1
Você pode migrar um nó da V5.0.x sem pará-lo. No entanto, não é necessário executar o nó para migrar sua configuração. As ferramentas de migração podem recuperar todos os dados de configuração enquanto o nó está parado. E além disso, é necessário parar o nó antes de iniciar o nó da V5.1 que está sendo instalado. Portanto, você pode parar o nó agora.
Selecione a opção de migração, quando ela aparecer.
Utilize a ferramenta First Steps quando ela aparecer no final da instalação do produto ou execute você mesmo o teste de verificação de instalação, se a ferramenta First Steps não aparecer por algum motivo.
Você pode desinstalar o servidor V5.0.x para sua comodidade.
Você pode utilizar as ferramentas de migração para migrar entre duas máquinas.
Antes de Começar
Normalmente, você utilizaria as ferramentas de migração WASPreUpgrade e WASPostUpgrade da V5.1 do WebSphere Application Server para fazer upgrade da V5.0.x para a V5.1 na mesma máquina.
No entanto, há alguns cenários onde você deve migrar a configuração da V5.0.x em uma máquina para a V5.1 em uma máquina diferente. Um desses cenários é a instalação de novas máquinas no ambiente da V5.1 mais recente, mas há necessidade de migrar a configuração da V5.0.x existente em outras máquinas.
Essa tarefa descreve como utilizar as ferramentas de migração da V5.1 para desempenhar a migração.
A ferramenta WASPreUpgrade salva a configuração da V5.0.x existente em um diretório de migration-specific-backup. A ferramenta WASPostUpgrade utiliza esse diretório para adicionar as definições de configuração antigas ao novo ambiente V5.1.
Etapas para Esta Tarefa
Nesse CD encontra-se o diretório migration/bin. Esse diretório contém um ambiente especial que você pode utilizar para executar a ferramenta WASPreUpgrade sem instalar a V5.1.
Salve a configuração no diretório migration-specific-backup na máquina V5.0.x.
WASPreUpgrade /opt/tmp/migration-specific-backup /opt/websphere/appserver
A ferramenta WASPreUpgrade fornece o status para a tela e para arquivos do log no diretório /migration-specific-backup. Os nomes de arquivos de logs ASCII começam com a ferramenta "WASPreUpgrade" de texto e incluem uma data e hora.
Utilize o ftp, o armazenamento compartilhado ou algum outro mecanismo para copiar o arquivo para a nova máquina.
Utilize a ferramenta WASPostUpgrade no diretório AppServer/bin do diretório raiz de instalação da V5.1, para adicionar a configuração da V5.0.x à configuração da V5.1.
WASPostUpgrade /opt/tmp/migration-specific-backup
A ferramenta WASPostUpgrade registra informações detalhadas específicas a cada bean corporativo implementado, no arquivo /migration-specific-backup/WASPostUpgrade.log.
Faça estas alterações:
Pode ser preciso alterar os IDs de usuários e senhas, se eles não forem idênticos àqueles em uso na máquina V5.0.x.
A configuração pode se referir a outros produtos ou configurações de software que não existem na nova máquina. Por exemplo, a máquina antiga pode ter um banco de dados. Modifique o datasource para apontar para o banco de dados na máquina antiga.
Você pode migrar uma versão anterior do release do WebSphere Application Server Versão 3.5.x ou Versão 5.0.x que está sendo executada em um sistema operacional que a Versão 5.1 não suporta.
Etapas para Esta Tarefa
Há duas opções. Você pode executar o comando do diretório migration\bin (ou migration/bin) no platform_root do CD-ROM Versão 5.1. Ou, pode copiar os arquivos no diretório do CD-ROM para um diretório criado na unidade de disco rígido.
Identifique o release Versão 3.5.x ou 5.0.x e identifique um diretório de backup onde o comando armazena arquivos de configuração e aplicativos de migração da versão anterior. Consulte o tópico WASPreUpgrade para obter a sintaxe de comando.
Identifique o diretório de backup e o local dos arquivos de configuração.
Unidade_de_CD:\WASPreUpgrade backupDirectory filepath\WebSphere\AppServer yourNodeName
Se isso funcionar, vá para a Etapa 4. Se não funcionar por algum motivo, desempenhe as etapas 2B à 2F.
Altere as seguintes variáveis:
Identifique o diretório de backup e o local dos arquivos de configuração.
yourMigrationDirectory\WASPreUpgrade backupDirectory filepath\WebSphere\AppServer yourNodeName
Se possível, mantenha o mesmo nome do sistema e senhas do sistema antigo. Coloque todos os arquivos do banco de dados relacionados a aplicativos que estão sendo migrados, no mesmo caminho que o sistema anterior. Em geral, tente manter os mesmos caminhos. No entanto, não instale a Versão 5.1 no mesmo diretório que a versão anterior. Se você não alterar os caminhos e nomes, poderá editar os arquivos de configuração XML para refletir as alterações. Faça tais alterações antes de executar o comando WASPostUpgrade a seguir.
Especifique o diretório de backup (e qualquer nome de arquivo de configuração que não seja padrão no diretório) criado pelo comando WASPreUpgrade. Consulte o tópico WASPostUpgrade para obter a sintaxe de comando correta.
install_root\bin\WASPostUpgrade WAS_HOME\migration
Este capítulo cobre os seguintes tópicos de migração:
No IBM WebSphere Studio Site Developer Versão 5.1.1, há uma nova função Server Targeting adicionada. Por padrão, essa função está desativada, você precisa ativá-la na página Preferences do J2EE selecionando Window > Preferences > J2EE. Detalhes funcionais sobre a função Server Targeting podem ser localizados na documentação do produto IBM WebSphere Studio Site Developer. Quando a função estiver ativada, você terá a opção de atingir um determinado servidor de aplicativos. Esse recurso foi implementado para suportar o JDK 1.4, que é o JRE para o WebSphere Application Server Versão 5.1 fornecido com o IBM WebSphere Studio Site Developer Versão 5.1.1. Os projetos EJB que se beneficiam do suporte Server Targeting não têm compatibilidade reversa com as versões anteriores do IBM WebSphere Studio Site Developer, por isso, não podem ser compartilhados com usuários que trabalham em versões anteriores do IBM WebSphere Studio Site Developer (por exemplo, IBM WebSphere Studio Site Developer Versão 5.1, IBM WebSphere Studio Site Developer Versão 5.0.1). O IBM WebSphere Studio Site Developeroferece uma maneira de obter compatibilidade reversa com esse recurso ativado e é descrito em "Compatibilidade Reversa com o Suporte Ativado do Server Targeting". O motivo dessa incompatibilidade é que a função do Server Targeting altera o arquivo .classpath em um projeto do J2EE e as novas entradas do arquivo .classpath não podem ser reconhecidas por versões anteriores do WebSphere Application Server - Express.
Com o suporte ativado do Server Targeting, os projetos J2EE com servidores alcançados podem ser revertidos para não utilizarem o suporte do Server Targeting, modificando o servidor de destino para uma opção No target server specified disponível no diálogo Modify Target Server. O diálogo Modify Target Server é ativado a partir do menu pop-up (Target Server > Modify) em um projeto J2EE na exibição Resource Navigator ou J2EE Perspective. O servidor de destino também pode ser modificado para um servidor Sem destino especificado na página de propriedades do J2EE (Properties > J2EE) para projetos EAR, EJB, Application Client e Connector. Para um projeto da Web, a definição do servidor de destino encontra-se na página de propriedades da Web (Properties > WEB). Detalhes funcionais sobre a função de modificação de Destino do Servidor podem ser localizados na documentação do IBM WebSphere Studio Site Developer. Quando a opção No target server specified é utilizada, o arquivo .classpath é revertido para o estilo compatível com as versões anteriores do IBM WebSphere Studio Site Developer e o .server é removido do projeto.
Devido a uma alteração no JDK 1.4, o usuário deve especificar um pacote Java quando utilizar os assistentes para Páginas da Web do Banco de Dados e do Java Bean para gerar páginas para a serem executadas no IBM WebSphere Studio Site Developer Versão 5.1.1. Esse problema ocorrerá, se o gabarito View Bean for utilizado para o assistente para Páginas da Web do Java Bean ou para o Padrão de Detalhes Principais do Java Beans do IBM Database Access. Isso se aplica a projetos que contêm páginas e arquivos .java anteriormente gerados com esses assistentes que não especificaram um pacote durante a criação. Para o código que foi anteriormente gerado, mova os arquivos .java para um pacote. Em seguida, atualize os arquivos .jsp, atualize as instruções de importação e as informações sobre classes. No arquivo web.xml do projeto, atualize a entrada servlet-class.
Este capítulo cobre os seguintes tópicos de migração:
O IBM WebSphere Studio Site Developer Versão 5.1.1 é baseado no novo WSWB (WebSphere Studio Workbench) 2.1.2 com base no Eclipse. Há algumas diferenças entre as versões 2.1.2 e 2.0.3 ou 2.0.2. Para obter uma informação detalhada sobre as diferenças, consulte o arquivo leia-me localizado no diretório WS_Installdir\eclipse\readme (em que WS_Installdir é o caminho onde você instalou o IBM WebSphere Studio Site Developer.
O IBM WebSphere Studio Site Developer Versão 5.0 foi baseado no WSWB 2.0.2 com base no Eclipse e o IBM WebSphere Studio Site Developer Versão 5.0.1 foi baseado no WSWB 2.0.3 com base no Eclipse. Não há diferenças significativas entre o 2.0.2 e o 2.0.3. O release do IBM WebSphere Studio Site Developer Versão 5.0.1 era um fix pack do Gerenciador de Atualização instalado na parte superior do IBM WebSphere Studio Site Developer Versão 5.0.
Quando o IBM WebSphere Studio Site Developer Versão 5.1.1 é iniciado pela primeira vez utilizando um espaço de trabalho do IBM WebSphere Studio Site Developer Versão 5.0 existente, aparece uma caixa de diálogo mostrando uma maneira de migrar da Versão 5.0. Clique em OK para migrar do espaço de trabalho da Versão 5.0 ou clique em Cancel para parar o início do IBM WebSphere Studio Site Developer.
Quando o espaço de trabalho é migrado ainda é possível utilizá-lo com a Versão 5.0, pois os metadados dos novos recursos de projeto são ignorados e podem ser lidos pela Versão 5.0. Não é possível fazer nenhuma alteração na Versão 5.0 aos projetos no espaço de trabalho que teriam efeito sobre os metadados ou sobrescreveriam os metadados do novo recurso de projeto para projetos.
Migrar projetos Java da Versão 5 ou da Versão 5.0.1 é muito simples e automático. Quando os projetos são carregados no espaço de trabalho da Versão 5.1.1, não ocorrem alterações de metadados nos arquivos .classpath ou .project, a menos que você tente utilizar os novos recursos disponíveis na Versão 5.1.1.
É necessário cuidado especial quando um projeto em um repositório de equipe está sendo carregado e operado por desenvolvedores utilizando o IBM WebSphere Studio Site Developer Versão 5 e IBM WebSphere Studio Site Developer Versão 5.1.1. O problema geral é que a existência, o conteúdo e a interpretação de arquivos de metadados nos espaços de trabalho podem ser específicos para um recurso específico ou versão de plug-in e diferir entre as versões. As garantias de compatibilidade de espaços de trabalho cobrem apenas os casos em que todos os desenvolvedores fazem upgrade dos espaços de trabalho do IBM WebSphere Studio Site Developer na etapa travada. Nesses casos não deve haver problemas com metadados compartilhados. No entanto, quando alguns desenvolvedores estão trabalhando no IBM WebSphere Studio Site Developer Versão 5.1 enquanto outros estão trabalhando no IBM WebSphere Studio Site Developer Versão 5, não existem essas garantias. Esta seção aconselha sobre o que fazer e o que não fazer.
O modo de falha típica é reconhecido pelo usuário do IBM WebSphere Studio Site Developer Versão 5.1.1. Os metadados da Versão 5.1.1 são perdidos quando um usuário da Versão 5 salva alterações e consolida os arquivos de metadados atualizados no repositório. A seguir, veja algumas coisas que podem dar errado:
Segue uma lista de detalhes a serem observados quando o projeto for compartilhado entre usuários do IBM WebSphere Studio Site Developer Versão 5.1.1 e Versão 5 ou Versão 5.0.1:
Esse suporte foi adicionado no IBM WebSphere Studio Site Developer Versão 5.1.1. As informações sobre os recursos vinculados estão gravadas no arquivo .project.
Recomendação: Não utilize. Melhor ainda, desative os recursos vinculados utilizando a página de preferências Workbench > Linked Resources.
As informações sobre construtores de ferramentas externas estão gravadas no arquivo .project. O formato das informações alteradas entre a Versão 5 e a Versão 5.1.1. Os construtores criados ou alterados na Versão 5.1.1 utilizam o novo formato, que não é compreendido por um espaço de trabalho da Versão 5. Os construtores criados na Versão 5 utilizam o formato antigo e continuam funcionando na Versão 5.1.1.
Recomendação: Sempre crie ou edite construtores de ferramentas externas a partir de um espaço de trabalho da Versão 5.
Esse suporte foi adicionado. Essas informações estão gravadas no arquivo .classpath.
Recomendação: Não especifique padrões de exclusão. Melhor ainda, desative os padrões de exclusão utilizando a página de preferências Java > Compiler > Build Path.
Esse suporte foi adicionado. Essas informações estão gravadas no arquivo .classpath.
Recomendação: Não especifique nada diferente da pasta de saída padrão (para todo o projeto). Melhor ainda, desative as diversas localizações de saída utilizando a página de preferências Java > Compiler > Build Path.
Ao conectar um arquivo ZIP de origem a uma biblioteca JAR no caminho de construção Java, o prefixo do caminho raiz da origem é deduzido automaticamente. Isso foi alterado a partir da Versão 5, em que o prefixo podia ser definido explicitamente através interface com o usuário e explicitamente gravado no arquivo .classpath. Conseqüentemente, um projeto Java criado em um espaço de trabalho 5.1.1 pode não localizar a origem conectada.
Utilize a Versão 5 para especificar o caminho de raiz anexa de origem. Na Versão 5.1.1, é fornecida flexibilidade adicional de conexão da origem. Você pode fornecer uma pasta em vez de um arquivo JAR ou ZIP como conexão da origem e pode conectar a origem a uma pasta de arquivos de classe; essa funcionalidade não está disponível na Versão 5 (na qual as informações da Versão 5.1.1 são ignoradas).
A utilização do PDE por contêineres do caminho de classe foi adicionada. Os contêineres do caminho de classe estão gravados no arquivo .classpath. Se os contêineres do caminho de classe PDE forem utilizados, um espaço de trabalho da Versão 5 terá entradas do caminho de classe não-resolvidas e, portanto, a maioria das capacidades Java (incluindo compilação, pesquisa, execução, depuração) não produzirá os resultados esperados.
Recomendação: Assegure-se de que a definição na página de preferências Plug-in Development > Java Build Path Control para a utilização de contêineres do caminho de classe esteja desativada antes de criar quaisquer novos projetos de plug-in (ou fragmento).
Os nomes de pastas são Java Source e Web Content. Os nomes das pastas padrão para novos projetos da Web são configuráveis por meio de uma página de preferências (Window > Preferences > Web Tools > New Project). Os nomes padrão agora são JavaSource e WebContent. Esses nomes padrão serão utilizados apenas para novos projetos da Web. Os projetos da Web criados em versões anteriores a esse release continuarão a funcionar utilizando os nomes antigos. O mesmo acontece com os projetos Estáticos da Web.
Se você optar por alterar os nomes das pastas de origem para projetos 4.0.x e 5.0 na Versão 5.1.1, utilize a ação do menu pop-up Rename na exibição Navigator. A ação do menu pop-up Rename renomeia os nomes das pastas e corrige o caminho de construção Java para os projetos da Web 4.0.x e 5.0.x.
Para a pasta JavaSource, a ação do menu pop-up Rename funciona na exibição Project Navigator e na exibição Packages. Para a pasta WebContent, a ação do menu pop-up Rename funciona na exibição Resource Navigator e na exibição Project Navigator.
Se um projeto da Web de uma versão anterior a esse release for salvo em um repositório SCM e, em seguida, carregado na Versão 5.1, ele manterá a estrutura antiga com as pastas source e webApplication. Qualquer uma das duas estruturas será construída corretamente.
O tempo de execução das ferramentas do Struts foi atualizado da Versão 1.1 Beta 2 na Versão 5 para a Versão 1.1. No IBM WebSphere Studio Site Developer Versão 5 (Disponibilidade Geral), ao criar um projeto da Web, você tem a opção de adicionar o suporte a Struts ao projeto. Você pode optar pelo Struts 1.0.2 ou pelo Struts 1.1 Beta 2. No IBM WebSphere Studio Site Developer Versão 5.1.1, a última opção é substituída pelo Struts 1.1. Se tiver criado projetos da Web do Struts 1.1 Beta 2 no IBM WebSphere Studio Site Developer Versão 5.0, você pode convertê-los para o Struts 1.1, porém isso não é necessário, pois o Struts 1.1 Beta 2 ainda é suportado. Caso possua projetos da Web do Struts 1.1 Beta 2 que deseja converter para o Struts 1.1, será necessário proceder da seguinte forma:
Todas as informações acima também serão aplicáveis se você estiver movendo um projeto da Web do Struts 1.1 Beta 3 no IBM WebSphere Studio Site Developer Versão 5.0.1 para o Struts 1.1.
As ferramentas de serviços da Web adicionaram dois novos protocolos de tempo de execução do IBM WebSphere Application Server Versão 5.0.2 que são executados somente no WebSphere Application Server Versão 5.0.2. Não deve haver migração obrigatória, pois o IBM WebSphere Studio Site Developer Versão 5.1 e o WebSphere Application Server Versão 5.0.2 suportarão os protocolos de tempo de execução novos e antigos. O IBM WebSphere Studio Site Developer Versão 5.1 irá gerar e implementar três protocolos de tempo de execução de artefatos de serviços da Web: o antigo protocolo de tempo de execução "IBM SOAP" que é executado no WebSphere Application Server Versão 4.x e Versão 5.x; o novo protocolo de tempo de execução "IBM WebSphere 5.0.2 runtime" que é executado apenas no WebSphere Application Server Versão 5.0.2 e o novo protocolo de tempo de execução "Apache Axis 1.0" que é executado apenas no WebSphere Application Server Versão 5.0.2.
Os usuários devem ser capazes de reutilizar os arquivos EAR e WAR relacionados a serviços da Web e projetos da Versão 5 sem nenhuma alteração na Versão 5.1.1. Para que convertam os clientes e serviços da Web para o novo protocolo de tempo de execução do IBM WebSphere 5.0.2 e tirem vantagem dos padrões JSR 101, 109, WS-I e WS-Security, eles terão que ser gerados novamente através do assistente para serviços da Web. O explorador de serviços da Web continuará automaticamente a ler os favoritos do usuário, embora o arquivo de dados físicos seja movido automaticamente para uma nova localização.
Ao migrar um espaço de trabalho da Versão 5, você receberá uma mensagem de erro pop-up "Problems occurred restoring workbench". Essa mensagem aparecerá se a perspectiva Profiling estiver aberta no momento da migração e se as exibições Heap ou Instance Statistic estiverem visíveis na perspectiva Profiling. Isso ocorre porque as exibições Heap e Instance Statistic existentes na Versão 5 foram removidas. Essa mensagem também aparecerá se a perspectiva Profiling estiver aberta no espaço de trabalho no momento da migração. A mensagem de erro pode ser ignorada com segurança clicando em OK.
Para utilizar um gabarito personalizado que foi criado na Versão 5, você deve carregar o gabarito personalizado, reconectá-lo ao banco de dados e salvá-lo. Na próxima vez que você recarregar o gabarito personalizado salvo, a conexão será verificada.
Os artefatos gerados do J2EE 1.2 criados nesse release podem não ser lidos pelo IBM WebSphere Studio Site Developer Versão 4.0.3 e executados nos ambientes de teste da Versão 4.0.3. Como o assistente Template não foi fornecido com a Versão 4.0.3, não é mantida a compatibilidade reversa para essa versão.
Os aplicativos de gabarito gerados nesse release podem ser executados na Versão 5, se nas preferências do projeto da Web a pasta de origem Java for denominada "Java Source" e a pasta de conteúdo da Web for denominada "Web Content".
Este capítulo abrange a migração do IBM WebSphere Studio Site Developer Versão 4.0.x para a Versão 5.
Há dois métodos suportados, que podem ser utilizados para migrar seus projetos do IBM WebSphere Studio Site Developer Versão 4.0.x para Versão 5. Cada um desses métodos está descrito em mais detalhes abaixo:
Observe que a migração da Versão 4 para a Versão 5 não altera automaticamente o nível J2EE do projeto, visto que a Versão 5 ainda pode ser compilada e implementada no WebSphere Application Server Versão 4. Todos os tipos de projetos J2EE, inclusive projetos da Web, podem ser migrados utilizando o assistente J2EE Migration disponível no IBM WebSphere Studio Site Developer. Para acessar o assistente J2EE Migration, clique com o botão direito em um projeto do tipo J2EE e selecione Migrate > J2EE Migration Wizard.
Segue uma lista parcial dos aperfeiçoamentos desde a Versão 4.0.x:
O WebSphere InfoCenter [www.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter/ index.html] tem as seguintes informações:
Migrating to WebSphere V5.0 An End-to-End Migration Guide é um bom recurso para obtenção de informações sobre migração da Versão 3.5 e 4.0 para a Versão 5 [www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246910.pdf].
A página de downloads do WebSphere Application Server [www14.software.ibm.com/webapp/download/product.jsp?s=p&id=TDUN-49EVRT& type=s&dt=DIAGNOSTIC+TOOL] possui ferramentas para ajudar a converter seu aplicativo:
Se seus projetos tiverem dependências circulares, a Versão 5 relata um erro de construção. Você pode entrar em Window > Preferences > Java > Compiler, selecionar a guia Build Path e limpar a caixa de opções Abort building on build path errors.Observe que isso não causará mais a interrupção da construção, mas ainda haverá um ou mais erros de 'dependência circular' de construção mostrados na exibição Task (mesmo quando a construção for bem-sucedida). Nesse caso, você pode transformar esses erros em avisos selecionando a guia Other e alterando a preferência no menu drop down Circular Dependencies.
No IBM WebSphere Studio Site Developer Versão 5, há alterações de estrutura do projeto interno da Versão 4.0.3. Um WAR da Web do J2EE 1.2 da Versão 5, quando exportado com a origem Java, será importado para o IBM WebSphere Studio Site Developer Versão 4 e a pasta do código fonte será automaticamente convertida para o nome correto e estará apta a construir. O projeto da Web ainda é executado corretamente no WebSphere Application Server Versão 4 da mesma maneira quando um projeto da Versão 4 é importado para a Versão 5, porque a pasta do código fonte é automaticamente convertida para o nome correto. Para obter informações adicionais sobre alterações de nome da pasta, consulte "Estruturas de Projetos da Web do IBM WebSphere Studio Site Developer"
A estrutura interna do projeto da Web no IBM WebSphere Studio Site Developer Versão 5 é diferente da do IBM WebSphere Studio Site Developer Versão 4.0.x. Essa diferença não está relacionada ao J2EE 1.2 versus J2EE 1.3, mas é uma alteração na utilização da ferramenta.
Na Versão 4, os projetos da Web eram projetos da Web dinâmicos por padrão e apareciam na exibição Navigator com uma pasta source e uma pasta webApplication. Na Versão 5, se você criar um projeto da Web dinâmico, ele aparecerá com uma pasta Java Source em vez de uma pasta source e uma pasta Web Content em vez de webApplication.
No entanto, se um projeto da Web da Versão 4 for salvo e um repositório SCM e, em seguida, carregado na Versão 5, ele manterá a estrutura antiga com as pastas origem e webApplication. Qualquer uma das duas estruturas irá construir corretamente na Versão 5.
Na Versão 5, você pode criar projetos estáticos, assim como projetos da Web dinâmicos.
Projetos da Web estáticos contêm apenas recursos estáticos como HTML, Java Scripts, imagens, texto, etc. e nenhum conteúdo dinâmico. Os projetos da Web estáticos podem ser executados e servidos por um servidor da Web HTTP tradicional e não precisam de um Servidor de Aplicativos da Web.
Os projetos da Web dinâmicos contêm recursos J2EE dinâmicos como servlets, JSPs, filtros e metadados associados, além dos recursos estáticos. Ao criar projetos da Web dinâmicos, você pode incluir páginas em estilo cascata e bibliotecas de marcação JSP, para poder começar o desenvolvimento com um conjunto mais rico de recursos de projetos. Projetos da Web dinâmicos estão sempre incorporados nos projetos do Enterprise Application e são executados somente nos Servidores de Aplicativos da Web.
Essa é a forma recomendada para mover espaços de trabalho da Versão 4.0.x para o IBM WebSphere Studio Site Developer Versão 5. Esse é o único método que migra todas as informações, incluindo as informações do caminho de construção do projeto.
Dica: Na Versão 4, o diretório da área de trabalho está localizado no diretório de instalação, por padrão. Na Versão 5, o padrão mudou para um diretório denominado workspace no diretório My Documents. Para substituir a localização onde seu trabalho está armazenado, utilize a opção -data no comando quando iniciar o workbench.
Para ClearCase: Utilize um espaço de trabalho limpo da Versão e para cada projeto selecionado para ser carregado, selecione File > Import > Existing WebSphere Studio 4.x ClearCase Project into Workspac.
Considerações Pós-migração:
The project was not built since it is involved in a cycle or has classpath problems. Missing required source folder: /MyHomePageExample403/source.
Os arquivos de extensão do aplicativo da Versão 4 do EAR IBM e os arquivos de configuração do servidor continham referências a caminhos absolutos. Após a migração destes para a Versão 5, é necessário abri-los com seu editor (o qual automaticamente alterará suas referências de caminho absoluto anteriores às novas referências relativas).
The IBM extensions file contains deprecated absolute paths. This can be auto-corrected and should be saved. This will remove the paths from the file, and only needs to be done once. Would you like to autocorrect?
Há outros fornecedores SCM que oferecem plug-ins SCM para o IBM WebSphere Studio Site Developer. Você pode procurar na lista de fornecedores www.ibm.com/software/ad/studioappdev/partners/scm.html.Como parte de sua validação do Ready for IBM WebSphere Studio software [www.developer.ibm.com/websphere/ready.html], todos os fornecedores SCM que forneceram um plug-in da Versão 4 terão assegurados o funcionamento das etapas de migração precedentes (salvas da Versão 4 para o repositório SCM, carregadas do repositório para a Versão 5) em seus sistemas.
Essa abordagem é parcialmente suportada e resultará em uma migração incompleta. As definições da interface com o usuário, as definições de depuração e a maioria das preferências são todas perdidas. Os nomes de projeto, os arquivos de origem do projeto e o caminho da construção Java do projeto (classpath) são retidos, mas nada mais pode ser garantido. Essa abordagem deve ser utilizada apenas se nenhum sistema SCM suportado estiver sendo utilizado e se for crítico reter informações do caminho de construção do projeto, que são perdidas quando você importa projetos que foram exportados da Versão 4. Você pode utilizar a área de trabalho existente da Versão 4.0.x, fazendo o seguinte:
As instruções sobre pós-migração descritas em Remoção Pós-migração das Referências de Caminho Absoluto do EAR e do Servidor de Configuração também se aplicam aqui.
Os problemas a seguir podem ocorrer, se você tentar migrar abrindo um espaço de trabalho da Versão 4.0 no IBM WebSphere Studio Site Developer Versão 5.
Para redefinir a variável de classpath JRE_LIB para uma localização válida, siga estas etapas. Faça isso mesmo se o valor parecer correto, quando abrir a janela Preferences pela primeira vez.
Se você não fizer isso, o valor de JRE_LIB poderá estar incorreto, causando muitos erros de construção nos arquivos Java.
Como verificação geral, verifique o valor de todas as outras variáveis de classpath.
O suporte para equipe foi alterado de forma significativa entre o Eclipse 1.0 e 2.0. O método de compartilhamento de projetos com o repositório também foi alterado.
Por padrão, os projetos são criados no diretório da área de trabalho. Se você tiver substituído o padrão para criar projetos em outro lugar, abra todos os seus projetos antes de fechar o workbench. Isso permitirá que o arquivo .project para aquele projeto seja gravado na localização correta. Falhar em abrir um projeto fechado cujo diretório está fora da área de trabalho resultará em um projeto que mascara o projeto real, com apenas um arquivo .project existente nele.
Será necessário remover os pontos de interrupção JSP existentes e redefini-los na área de trabalho migrada da Versão 5.
Para migrar dados relacionais de projetos do IBM WebSphere Studio Site Developer 4.0.3:
Os artefatos de dados relacionais serão restaurados.
Se você importou um arquivo de serviços da Web do 4.0.x, é possível que você receba as seguintes mensagens de erro:
Error The part 'result' has an invalid value 'anyElement' defined for its type. Type declarations must refer to valid values defined in a schema. Error The part 'return' has an invalid value 'findPatientResult' defined for its element. Element declarations must refer to valid values defined in a schema. Error The part 'response' has an invalid value 'findPatientResponse' defined for its element. Element declarations must refer to valid values defined in a schema.
A solução alternativa é:
Para acessar o assistente J2EE Migration na Versão 5, siga as etapas abaixo:
Este capítulo documenta como migrar do WebSphere Studio Versão 4.0 (Advanced e Professional Edition) para o IBM WebSphere Studio Site Developer. Migrar do WebSphere Studio "Classic" Versão 4.0 para o IBM WebSphere Studio Site Developer Versão 5.0 envolve as seguintes etapas:
O recurso de publicação avançada (mapeamento de arquivos para estágios de publicação) e o recurso Page Detailer (análise de páginas da Web) do WebSphere Studio 'Classic' não estão disponíveis no IBM WebSphere Studio Site Developer. Alguns outros recursos do pacote de mídia do CD da Versão 4.0.x também não estão mais disponíveis. Por exemplo, o recurso Page Detailer para análise de páginas da Web, o recurso HotMedia(R) para tipos rich media, o editor Voice XML (movido para o WebSphere Everyplace(TM) Toolkit e o Portal Toolkit), DataBaseWizard para dispositivos interativos.
É recomendável ter conhecimento das seguintes limitações antes de migrar quaisquer de seus dados do WebSphere Studio:
Durante o processo de migração descrito abaixo, o WebSphere Studio cria um arquivo JAR que contém todos os seus arquivos de projeto, publicáveis e de origem, de um único servidor. Todos os arquivos visíveis na exibição Publishing do servidor padrão estarão em um pacote dentro do arquivo JAR. Em seguida, é possível importar o arquivo JAR para o IBM WebSphere Studio Site Developer.
Ao migrar projetos existentes, todas as informações sobre publicação do projeto e de estágio são perdidas durante a migração. Se o seu estágio tiver vários servidores, serão conservados apenas os arquivos publicados no servidor padrão. Dessa forma, para finalidades de migração, você deverá criar um novo estágio que tenha apenas um servidor.
Se você tiver mais de um servidor no seu estágio atual, crie um novo estágio chamado Migration com um único servidor perfazendo as seguintes etapas:
O nome do arquivo do descritor de configuração da Web padrão é serverName_web.xml, localhost_web.xml neste cenário. A menos que você especifique uma localização diferente, o arquivo .xml será salvo no diretório WEB-INF.
Agora você está pronto para testar seu aplicativo. Para testá-lo no servidor de testes padrão, siga estas etapas:
Para testar seu aplicativo em outros ambientes em tempo de execução do servidor, consulte a ajuda on-line do recurso Server Tools.
Este capítulo documenta como migrar do VisualAge(R) para Java, Professional Edition ou VisualAge para Java Enterprise Edition para o IBM WebSphere Studio Site Developer.
Instantiations, Inc., um Parceiro IBM, distribui um produto,
denominado CodePro Studio que fornece aperfeiçoamentos de produtividade para o
VisualAge para Java e o WebSphere Application Server - Express, incluindo
recursos de migração e coexistência. Para auxiliar os clientes do
VisualAge para Java a iniciar a migração, a Instantiations está oferecendo
utilização gratuita e ilimitada do recurso de exportação do VisualAge para
Java para o IBM WebSphere Studio Site Developer como parte de sua cópia para
avaliação por tempo limitado do CodePro Studio. Você pode fazer
download da cópia avaliação no endereço www.instantiations.com/vaj-migrate.
Para obter informações adicionais sobre o suporte de coexistência e migração
avançado no Instantiation, incluindo a exportação/importação bidirecional
completa de arquivos, criação de definições de exportação/importação,
sincronização de projetos e automação de tarefas, procure a Instantiations,
Inc. no endereçowww.instantiations.com/codepro/ws.
A seguir, uma lista parcial das alterações do VisualAge para Java:
As etapas a seguir delineiam como migrar do VisualAge para Java. São fornecidos abaixo detalhes sobre a execução de tais etapas:
Não há suporte para a migração em massa de projetos e recursos em versão do repositório do VisualAge para Java. É possível migrar apenas projetos e recursos que estão na área de trabalho do VisualAge para Java. Se quiser migrar uma cópia transformada em versão de um projeto ou recurso para o IBM WebSphere Studio Site Developer, deverá trazê-la para o espaço de trabalho do VisualAge para Java e, em seguida, migrá-la.
Exporte seus projetos para um arquivo JAR, seguindo estas etapas:
Inicie o IBM WebSphere Studio Site Developer, em seguida, crie os projetos apropriados. A seguir encontra-se um conjunto de diretrizes gerais de migração para ajudá-lo a decidir a que tipo de projeto do IBM WebSphere Studio Site Developer você deve importar seus arquivos:
Se o seu aplicativo usar servlets, será necessário definir os mapeamentos de servlet-URL no arquivo web.xml. Execute as seguintes etapas:
É necessário gravar as seguintes definições do VisualAge para Java e configurá-las no IBM WebSphere Studio Site Developer:
Caminho da classe do projeto
No VisualAge para Java, você define o classpath do projeto nas páginas Resources da janela Options (Window > Options > Resources). Depois de migrar seus projetos para o IBM WebSphere Studio Site Developer, você poderá configurar o classpath do projeto na janela Properties do projeto (clique com o botão direito no projeto e selecione Properties > Java Build Path. Clique na guia Libraries). Também é possível definir variáveis de classpath na janela Preferences (Window > Preferences > Java > Classpath Variables).
Associações de Recursos
Se você configurar uma associação entre um tipo de arquivo e um executável, de dentro do workbench poderá abrir um arquivo que esteja fora dele.
No VisualAge para Java, você configura as associações de recursos na janela Options (Window > Options > Resources > Resource Associations). Depois de migrar seus arquivos de recursos para o IBM WebSphere Studio Site Developer, você poderá configurar suas associações de recursos, utilizando a janela Preferences (Window > Preferences > Workbench > File Associations).
Formatador de Código
No VisualAge para Java, você configura suas opções de formatação de código na página Formatter da janela Options (Window > Options > Coding > Formatter). Depois de migrar seu código para o IBM WebSphere Studio Site Developer, você poderá configurar a formatação do código na janela Preferences (Window > Preferences > Java > Code Formatter).
Configuração do WTE
No VisualAge para Java, as definições de tempo de execução do Ambiente de Teste da Unidade WebSphere e do WebSphere Application Server estão em vários arquivos de propriedades no seguinte diretório: VisualAgeInstalldir\ide\project_resources\IBM WebSphere Test Environment\properties, onde VisualAgeInstalldir é o seu diretório de instalação do produto.
Se, por exemplo, você ativou o URL regravando no arquivo de propriedade session.xml, alterando a propriedade para true como demonstrado a seguir, <url-rewriting-enabled>true</url-rewriting-enabled>, poderá configurar essa propriedades no Ambiente de Teste do IBM WebSphere Studio Site Developer Versão 4.0. (Na perspectiva Server, abra a exibição Server Configuration, clique com o botão direito no servidor com o qual deseja trabalhar e clique em Open. Clique na guia Web e selecione a caixa de opções Enable URL rewrite).
Arquivos Java e Arquivos de Recursos do Projeto
O arquivo de propriedades default.servlet_engine contém o <root-uri> da raiz de contexto do(s) aplicativo(s) da Web do VisualAge para Java. Ao criar um Projeto da Web no IBM WebSphere Studio Site Developer, o diálogo Create a Web Project contém um campo Context root para esses dados.
As definições do aplicativo da Web em arquivos como VisualAgeInstalldir\ide\project_resources\IBM WebSphere Test Environment\hosts\default_host\default_app\servlets\default_app.webapp que você mesmo personalizou devem ser migradas para o arquivo your_Web_project\Web Content\WEB-INF\web.xml no IBM WebSphere Studio Site Developer. Por exemplo, se foram modificados nomes e caminhos de servlets no arquivo default_app.webapp, é necessário fazer as alterações correspondentes no arquivo web.xml.
Se o aplicativo for um projeto Java, apenas utilize o suporte normal de projetos Java do IBM WebSphere Studio Site Developer Run ou Debug para testá-lo.
Se o aplicativo utilizar o WebSphere Application Server , teste-o usando o WebSphere Application Server interno. Isto requer a criação e a inicialização de um servidor de testes padrão. Em um projeto da Web, clique com o botão direito do mouse na página HTML principal e selecione Run on Server para ativar o navegador da Web.
Para obter informações sobre o teste de outros tipos de projetos, consulte a ajuda on-line.
Se estiver utilizando o WebSphere Application Server como ambiente em tempo de execução, implemente seu aplicativo utilizando o recurso Server Tools do IBM WebSphere Studio Site Developer.
Os projetos do IBM WebSphere Studio Site Developer (e suas definições associadas) podem ser compartilhados entre desenvolvedores. Para fazer isso, salve um projeto no servidor do SCM (Software Configuration Management) do IBM WebSphere Studio Site Developer, em seguida, extraia-o para outro membro da equipe no IBM WebSphere Studio Site Developer.
Para obter informações sobre suporte de equipe no IBM WebSphere Studio Site Developer Versão 4.0, consulte www.ibm.com/websphere/developer/library/techarticles/0108_karasiuk/0108_karasiuk.html
Também há informações no guia e na ajuda on-line da Instalação sobre o suporte de equipe no IBM WebSphere Studio Site Developer.
Este capítulo fornece instruções sobre como migrar aplicativos criados no recurso Visual Composition Editor do VisualAge para Java no Visual Editor para Java no WebSphere Application Server - Express:
Esta etapa é opcional, mas altamente recomendada (especialmente se seu aplicativo possuir conexões) pelas razões a seguir.
Para salvar as informações dos metadados aprimorados antes da migração:
Suas classes estão prontas agora para serem importadas para o WebSphere Application Server - Express. Consulte referência anterior no Capítulo 7, "Migrando do VisualAge para Java para o IBM WebSphere Studio Site Developer". Depois que os programas de origem anteriores do Visual Composition Editor forem importados para o WebSphere Application Server - Express, você poderá mantê-los no Visual Editor para Java.
Este capítulo cobre os seguintes tópicos de migração:
Para obter explicações detalhadas sobre o que está envolvido, consulte o artigo sobre J2EE Class Loading Demystified (www.ibm.com/websphere/developer/library/techarticles/0112_deboer/ deboer.html) (Módulos do J2EE e caminhos de classe) e sobre o desenvolvimento de JARs do utilitário J2EE (www.ibm.com/websphere/developer/library/techarticles/0112_deboer/ deboer2.html) (JARs do Java em módulos do J2EE). Eles oferecem excelente conhecimento e aconselhamento técnico.
A maneira recomendada para utilizar um arquivo JAR de terceiros em um projeto da Web é importá-lo (mantendo-o como um arquivo JAR) na pasta de bibliotecas de seu projeto da Web. Esta é a única maneira transferível e definida pelo J2EE para a utilização de um arquivo JAR e garante que não será necessário fazer alterações ao implementá-lo em outro servidor.
Para utilizar um arquivo JAR externo em um único projeto da Web, siga as etapas abaixo. Se for necessário utilizar o arquivo JAR em um vários projetos da Web, siga então as etapas descritas em "A Maneira Recomendada de Utilizar um JAR de Terceiros para Uso em Vários Projetos Web" .
A maneira recomendada para utilizar um arquivo JAR de terceiros com dois ou mais projetos do Web é importá-lo (mantendo-o como um arquivo JAR) em um projeto EAR (Enterprise Application). Esta é a única maneira transferível e definida pelo J2EE para a utilização de um arquivo JAR e garante que não será necessário fazer alterações ao implementá-lo em outro servidor.
Para utilizar um arquivo JAR com vários projetos do Web, siga as etapas a seguir. Se você precisar apenas utilizar o arquivo JAR em um projeto da Web, siga as etapas na seção anterior.
Você também pode deixar o arquivo JAR fora do WebSphere Application Server - Express e adicioná-lo ao caminho de compilação de Java e ao caminho da classe da instância do servidor. Isto não é recomendado porque seu aplicativo não será transferido com facilidade. Quando for movido para um servidor diferente, será sempre necessário atualizar o caminho da classe do servidor. Além disso, você precisa assegurar que seus arquivos class não conflitem com outras versões de arquivos class similares que já se encontram no classpath do servidor (e são necessários para o servidor ou seus outros aplicativos). Se você decidir utilizar essa abordagem, execute as seguintes etapas:
O recurso de auto-compilação potente do WebSphere Application Server - Express pode diminuir o desempenho da compilação durante compilações complexas de vários projetos. Há várias maneiras de controlar essas construções automáticas (arquivos dependentes, projetos ativos e inativos e projetos em formato de origem ou JAR), mas estas opções podem tornar-se bem complicadas. Há um artigo que explica as opções e como otimizar o desempenho de sua construção. Consulte o artigo do WebSphere Developer Domain "Optimizing Multi-Project Builds Using dependent Project JARs in WebSphere Studio Application Developer" (www.ibm.com/websphere/developer/library/techarticles/0204_searle/ searle.html).
Você pode utilizar Ant com o WebSphere Application Server - Express para automatizar as compilações de produção. Há um artigo em várias partes, que explica os seguintes itens:
Consulte o artigo do WebSphere Developer Domain "Utilizando Ant com o WebSphere Studio Application Developer" (www.ibm.com/websphere/developer/library/techarticles/0203_searle/ searle1.html).
Este capítulo contém exemplos de migração, para ajudá-lo a aprender mais sobre como migrar do VisualAge para Java e do WebSphere Studio "Classic" para o WebSphere Application Server - Express IBM WebSphere Studio Site Developer.
Descrição
Este é o exemplo FindTheLeapYears fornecido com o VisualAge para Java Versão 4.0. Informações sobre ele podem ser localizadas na ajuda on-line do VisualAge para Java (Samples > JSP/Servlet Development Environment).
Visão Geral sobre Migração
Siga as etapas abaixo para migrar o exemplo do VisualAge para Java para o IBM WebSphere Studio Site Developer. Estas etapas são discutidas mais detalhadamente abaixo:
Importe os arquivos de origem Java para o diretório de origem do projeto LeapYear executando as etapas a seguir:
Importe os arquivos de recursos para o projeto LeapYear no diretório WebContent, executando as seguintes etapas:
Agora é necessário fazer todas as alterações de aplicativos devido às pequenas alterações na estrutura origem/aplicativo:
Neste momento, a amostra foi migrada para o IBM WebSphere Studio Site Developer. Resta apenas criar um projeto de servidor do IBM WebSphere Studio Site Developer e testar a amostra no ambiente de teste do WebSphere.
Agora, é necessário especificar o seu projeto EAR na configuração do servidor:
Descrição
Você deve trabalhar com o WebSphere Studio "Classic" Versão 4.0.x para este exemplo.
O exemplo com a qual iremos trabalhar é o YourCo. Para acessar essa amostra, abra a ajuda on-line (Help > WebSphere Studio 4.0 > How to > Work with the samples > Overview). Para carregar esta amostra, siga as instruções em Opening the Studio Samples (para o WebSphere Application Server 4.0) e carregue YourCo.war.
Antes de Iniciar
Etapas de Migração
Para migrar esta amostra do WebSphere Studio "Classic" para o IBM WebSphere Studio Site Developer, siga as etapas abaixo. Cada etapa é descrita mais detalhadamente abaixo.
(Opcional) Normalmente, você criaria uma nova etapa para uma migração, mas para a finalidade deste exemplo, utilize a etapa de Teste incluída no WebSphere Studio "Classic". Utilizando a etapa de Teste não haverá necessidade de editar manualmente os mapeamentos de servlet na etapa 8.
Para obter informações sobre como criar uma nova etapa para migração, consulte "Migrando do WebSphere Studio "Classic" para o IBM WebSphere Studio Site Developer".
a. com.ibm.db requires databeans.jar, b. com.ibm.webtools.runtime requires webtlsrn.jar, c. com.ibm.ejs.ns.jndi requires ns.jar, d. com.ibm.webshpere.advanced.cm.factory requires cm.jar, e. com.ibm.ejs.models.base.extensions.webappext.ServletExtensions requires ws-base-extensions.jar
Para corrigir este problema, o caminho de construção Java do projeto da Web deve ser modificado.
Neste momento, a amostra foi migrada para o IBM WebSphere Studio Site Developer. Resta apenas criar um projeto de Servidor do IBM WebSphere Studio Site Developer e testar a amostra no Ambiente de Teste do WebSphere.
Agora, é necessário especificar o seu projeto EAR na configuração do servidor:
Informações atualizadas sobre migração e outros tópicos estão disponíveis em www.ibm.com/websphere/developer/zones/studio/transition.html
As publicações a seguir e as páginas da Web fornecem informações gerais que podem ser úteis para trabalhar com o WebSphere Application Server - Express:
Leituras adicionais que podem ser interessantes:
Nota sobre Direitos Restritos para Usuários do Governo dos Estados Unidos - Uso, duplicação e divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM Corp.
Estas informações foram desenvolvidas para produtos e serviços oferecidos nos Estados Unidos. É possível que a IBM não ofereça os produtos, serviços ou recursos discutidos neste documento em outros países. Consulte um representante IBM local para obter informações sobre produtos e serviços disponíveis atualmente em sua área. Qualquer referência a produtos, programas ou serviços IBM não significa que apenas produtos, programas ou serviços IBM possam ser utilizados. Qualquer produto, programa ou serviço funcionalmente equivalente que não infrinja nenhum direito de propriedade intelectual da IBM pode ser utilizado em substituição a este produto, programa ou serviço. Entretanto, a avaliação e verificação da operação de qualquer produto, programa ou serviço não-IBM são de responsabilidade do Cliente.
A IBM pode ter patentes ou solicitações de patentes pendentes relativas a assuntos tratados neste documento. O fornecimento deste documento não garante ao Cliente nenhum direito sobre tais patentes. Pedidos de licença devem ser enviados, por escrito, para:
Gerência de Relações Comerciais e Industriais da IBM Brasil
Av. Pasteur, 138-146
Botafogo
Rio de Janeiro, RJ
CEP 22290-240
Para pedidos de licença relacionados a informações de DBCS (Conjunto de Caracteres de Byte Duplo), entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou envie pedidos de licença, por escrito, para:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
A IBM pode utilizar ou distribuir as informações fornecidas da forma que julgar apropriada sem incorrer em qualquer obrigação para com o Cliente.
O parágrafo a seguir não se aplica a nenhum país em que tais disposições não estejam de acordo com a legislação local: A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO "NO ESTADO EM QUE SE ENCONTRA" SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS GARANTIAS IMPLÍCITAS OU CONDIÇÕES DE NÃO-VIOLAÇÃO, MERCADO OU ADEQUAÇÃO A UM DETERMINADO PROPÓSITO. Alguns países não permitem a exclusão de garantias expressas ou implícitas em certas transações; portanto, essa disposição pode não se aplicar ao Cliente.
Estas informações podem conter imprecisões técnicas ou erros tipográficos. Periodicamente são feitas alterações nas informações aqui contidas; tais alterações serão incorporadas em futuras edições desta publicação. A IBM pode, a qualquer momento, aperfeiçoar e/ou alterar os produtos e/ou programas descritos nesta publicação, sem aviso prévio
Licenciados deste programa que desejam obter informações sobre este assunto com objetivo de permitir: (i) a troca de informações entre programas criados independentemente e outros programas (incluindo este) e (ii) a utilização mútua das informações trocadas, devem entrar em contato com:
Gerência de Relações Comerciais e Industriais da IBM Brasil
Av. Pasteur, 138/146
Botafogo
Rio de Janeiro, RJ
CEP 22290-240
Tais informações podem estar disponíveis, sujeitas a termos e condições apropriados, incluindo em alguns casos, o pagamento de uma taxa.
O programa licenciado descrito neste documento e todo o material licenciado disponível para ele são fornecidos pela IBM em conformidade com os termos do Contrato com o Cliente IBM, Contrato de Licença de Programa Internacional IBM ou qualquer outro contrato equivalente.
As informações relativas a produtos não-IBM foram obtidas junto aos fornecedores dos respectivos produtos, de seus anúncios publicados ou de outras fontes disponíveis publicamente. A IBM não testou estes produtos e não pode confirmar a precisão de seu desempenho, compatibilidade nem qualquer outra reivindicação relacionada a produtos não-IBM. Dúvidas sobre os recursos de produtos não-IBM devem ser encaminhadas diretamente a seus fornecedores.
Referências nestas informações a Web sites não-IBM são fornecidas apenas por conveniência e não representam de forma alguma um endosso a estes Web sites. Os materiais contidos nestes Web sites não fazem parte dos materiais deste produto IBM e a utilização desses Web sites é de inteira responsabilidade do Cliente.
Estas informações contêm exemplos de dados e relatórios utilizados nas operações diárias de negócios. Para ilustrá-los da forma mais completa possível, os exemplos podem incluir nomes de indivíduos, empresas, marcas e produtos. Todos estes nomes são fictícios e qualquer semelhança com nomes e endereços utilizados por uma empresa real é mera coincidência.
LICENÇA DE COPYRIGHT:
Estas informações contêm exemplos de programas aplicativos no idioma de origem, ilustrando as técnicas de programação em diversas plataformas operacionais. Você pode copiar, modificar e distribuir estes exemplos de programas sem a necessidade de pagar a IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com a interface de programação do aplicativo para a plataforma operacional para a qual os programas de exemplo são criados. Esses exemplos não foram testados completamente em todas as condições. Portanto, a IBM não pode garantir ou implicar a confiabilidade, manutenção ou função desses programas. Você pode copiar, modificar e distribuir estes exemplos de programas de qualquer maneira sem pagamento à IBM, com objetivos de desenvolvimento, utilização, marketing ou distribuição de programas aplicativos em conformidade com interfaces de programação de aplicativos da IBM.
Cada cópia ou parte desses programas de exemplo ou qualquer trabalho derivado, deve incluir um aviso de copyright com os dizeres:
(C) (nome da empresa) (ano). Partes deste código são derivadas dos Programas de Exemplo IBM Corp. (C) Copyright IBM Corp. 2000, 2003. Todos os direitos reservados.
As informações sobre interface de programação destinam-se a ajudá-lo a criar software aplicativo utilizando este programa.
Interfaces de programação de uso geral permitem desenvolver o software aplicativo que obtém os serviços das ferramentas desse programa.
No entanto, essas informações também podem conter informações sobre diagnósticos, modificações e ajustes. As informações sobre diagnósticos, modificações e ajustes são fornecidas para ajudá-lo a depurar o software aplicativo.
Aviso: Não utilize estas informações sobre diagnósticos, modificações e ajustes como uma interface de programação porque estão sujeitas a alterações.
Os termos a seguir são marcas comerciais ou marcas registradas da International Business Machines Corporation nos Estados Unidos e/ou em outros países:
Java e todas as marcas comerciais e os logotipos baseados em Java são marcas comerciais ou marcas registradas da Sun Microsystems, Inc. nos Estados Unidos e/ou em outros países.
ActiveX, Microsoft, Windows, Windows NT e o logotipo Windows são marcas comerciais ou marcas registradas da Microsoft Corporation nos Estados Unidos e/ou em outros países.
UNIX é uma marca registrada do The Open Group.
Outros nomes de empresas, produtos ou serviços, que podem estar indicados por asteriscos duplos (**), podem ser marcas comerciais ou marcas de serviço de terceiros.