IBM Rational Web Developer para Windows e Linux, Versão 6.0 : Guia de Migração
Capítulo 1. Migrando do WebSphere Studio V5.1, 5.1.1 ou 5.1.2
Capítulo 2. Atualizando Recursos de Tempo de Execução Faces para Projetos da Web do Rational Web Developer V6.0
Capítulo 3. Migrando Projetos do J2EE
Capítulo 4. Alterações nos Ambientes de Teste do WebSphere
Esta documentação fornece instruções para migrar do WebSphere
Studio Site Developer V5.1.x para o Rational Web Developer
V6.0.
As informações adicionais podem ser localizadas nos seguintes
tópicos:
As informações sobre a utilização do Rational Web Developer
podem ser encontradas na ajuda on-line.
Consulte www.ibm.com/developerworks/rational
para obter a documentação atualizada.
Para obter informações sobre como migrar de versões anteriores do
WebSphere Studio para a v5.x ou migrar do VisualAge para Java para o
WebSphere Studio, vá para o endereço www.ibm.com/software/awdtools/studioappdev/support/
e procure o "guia de migração".
Para migrar do WebSphere Studio V5.1.x:
- Antes da instalação, leia sobre a compatibilidade com o Eclipse V2.x e
WebSphere Studio V5.1.x. Observe que a
compatibilidade com releases anteriores não é suportada para projetos de
aplicativos de portlet migrados do Portal Toolkit
V5.0.2.2 com o WebSphere Studio
V5.1.2.
- Faça backup do espaço de trabalho do WebSphere Studio
V5.1.x.
- Instale o Rational Web Developer. Consulte o Guia de
Instalação (arquivo install.html) que está disponível
na raiz do primeiro CD do produto.
- Recomendado: Por padrão, a primeira vez que você
iniciar o Rational Web Developer, será solicitada a confirmação de
que você deseja utilizar um espaço de trabalho denominado
rationalsdp6.0\workspace. Ou seja, a caixa de diálogo
Ativador do Espaço de Trabalho aponta para o diretório que não é
seu espaço de trabalho do WebSphere Studio. Para explorar o novo
ambiente antes de migrar seu espaço de trabalho antigo, aceite o padrão
ou especifique algum outro novo nome de diretório ao iniciar o Rational Web
Developer. Você pode fazer isso, por exemplo, para que possa criar
um ou mais projetos de teste, ler sobre o que há de novo, (Ajuda
-> Bem-vindo), executar alguns dos novos tutoriais
(Ajuda -> Tutorials Gallery) ou fazer
experiências com algumas das novas amostras (Ajuda ->
Samples Gallery).
- Migre seus projetos para a V6.0. Os projetos criados no
WebSphere Studio V5.1.x podem ser migrados automaticamente para
a V6.0 da seguinte forma:
- Migrando um espaço de trabalho: Quando você estiver
pronto para migrar o espaço de trabalho da V5.1.x
definitivamente, inicie o Rational Web Developer com o espaço de trabalho
antigo. Um indicador de progresso confirma que seus projetos estão
sendo migrados automaticamente.
Notas: Durante a migração do espaço de trabalho,
uma caixa de diálogo Problemas é aberta com a mensagem
Não foi possível restaurar o layout do workbench.
Razão: Ocorreram problemas na restauração do
workbench. As mensagens de erro não têm nenhum impacto na
migração bem-sucedida do espaço de trabalho. Observe o nome da
perspectiva que não pôde ser restaurada clicando no botão
Detalhes na caixa de diálogo de erro e, em seguida, clique em
OK para fechar a caixa de diálogo.
Para restaurar a perspectiva:
- Feche a perspectiva, selecionando Janela -> Fechar
Perspectiva
- Reabra a perspectiva, selecionando Janela -> Abrir
Perspectiva.
- Nota:
- Para projetos EGL (Enterprise Generation Language) que utilizavam a
perspectiva da Web EGL no WebSphere Studio V5.1.2:
esta perspectiva foi removida no Rational Web Developer V6.0.
Todos os projetos EGL são migrados com segurança sem essa perspectiva no
Rational Web Developer V6.0. Faça o seguinte se tiver
utilizado a perspectiva da Web do EGL:
- Feche a perspectiva da Web do EGL.
- Ative as capacidades do EGL em Preferências (Janela ->
Preferências). Consulte a ajuda on-line para obter
detalhes sobre como ativar as capacidades do EGL.
- Selecione Janela -> Abrir Perspectiva e
escolha a perspectiva da Web.
- Migrando projetos carregados de um sistema SCM (Source Code
Management): Os projetos do WebSphere Studio 5.1.x
que existem em um sistema SCM são automaticamente migrados para a
V6.0 quando são carregados no Rational Web Developer.
- Migrando projetos importados utilizando o Intercâmbio de
Projetos: Os projetos exportados do WebSphere Studio
V5.1.2 ou V5.1.1 e importados para o Rational Web
Developer V6.0 utilizando o recurso Intercâmbio de Projetos são
automaticamente migrados para a V6.0. O recurso Intercâmbio
de Projetos estava disponível no WebSphere Studio V5.1.2 e
era um plug-in opcional para a V5.1.1.
Notas:
- Para cada projeto V5.1.x migrado para a V6.0, o
programa de migração automaticamente inclui um arquivo
.compatibility na pasta de projeto na V6.0. Esse arquivo
é utilizado para a finalidade de compatibilidade com releases anteriores
com o WebSphere Studio V5.1.x. Não edite ou exclua
esse arquivo. Consulte a seção sobre compatibilidade com o WebSphere Studio
V5.1.x para obter informações adicionais.
Importante:
- Se houver configurações de ativação de depuração
associadas ao espaço de trabalho que está sendo migrado, observe que
alguma configuração de ativação não será migrada
automaticamente. Para obter informações sobre como restaurar as
configurações de ativação para um espaço de trabalho migrado,
consulte Alterações do Depurador na V6.0.
- Se você utilizou o depurador XSLT ou o depurador EGL em projetos de seu
espaço de trabalho migrado, será necessário alterar o JRE (Java
Runtime Environment) instalado com o Rational Web Developer
V6.0. Consulte Alterações do Depurador na V6.0 para obter detalhes sobre como fazer essa
alteração.
- Se você tiver programas desenvolvidos utilizando o Enterprise
Generation Language que foram migrados para a V6.0, será
necessário observar se há novas palavras reservadas para EGL na
versão 6.0. Se você utilizar essas palavras como
variáveis ou nomes de partes, será necessário alterá-las.
Consulte Palavras Reservadas do EGL na V6.0
- O Driver JDBC de Rede do DB2 não é suportado no Rational Web
Developer V6.0. Se tiver criado conexões JDBC utilizando o
driver JDBC de Rede do DB2, não será possível reconectar ao Rational
Web Developer V6.0. Será necessário alterar a conexão
para utilizar um dos drivers JDBC suportados. Consulte a ajuda on-line
para obter informações adicionais sobre os drivers JDBC suportados na
V6.0.
- Se você tiver o conteúdo de arquivos da Web ou XML migrado a partir
do WebSphere Studio Site Developer V5.1.x que utilizou o
conjunto de caracteres Shift_JIS e incluiu caracteres selecionados do
fornecedor, será necessário especificar o conjunto de caracteres
Windows-31J.
- Se você tiver instalado plug-ins de fornecedores com o WebSphere Studio
Site Developer V5.1.x, será necessário obter os plug-ins
correspondentes para a V6.0 e reinstalá-los.
- Se você utilizar recursos que exijam o Agent Controller, faça seu
upgrade instalando a versão fornecida com o Rational Web Developer.
Para obter detalhes, consulte o Guia de Instalação.
- Para migrar do VisualAge Generator, consulte o Guia de Migração do
VisualAge Generator para EGL (Enterprise Generation Language) que
está disponível no formato PDF na seção "Instalando e Migrando" da
ajuda on-line no tópico de ajuda "Acessando o Guia de Migração do
VisualAge Generator para EGL." A cópia mais recente pode ser obtida
no endereço http://www.ibm.com/developerworks/rational/library/egldoc.html.
Ao abrir qualquer espaço de trabalho do WebSphere Studio
V5.1.x pela primeira vez no Rational Web Developer, ele é
automaticamente migrado. Depois de migrar um espaço de trabalho, ele
não poderá mais ser aberto no WebSphere Studio Site Developer.
Entretanto, os projetos no espaço de trabalho da V6.0 ainda podem
ser compartilhados com o WebSphere Studio V5.1.x, utilizando um
sistema SCM (Source Code Management) (como o Rational ClearCase), importando e
exportando o projeto utilizando o Intercâmbio de Projetos ou importando
archives e exportando projetos. Importante: Os
aplicativos de portlet do Portal Toolkit V5.0.2.2 que
forem migrados para o Portal Tools no Rational Web Developer V6.0
não serão compatíveis com releases anteriores.
- Nota:
- O seguinte não se aplica a projetos de aplicativos de portlets.
Os projetos V5.1.x existentes que são carregados para a
V6.0 a partir de um sistema SCM ou de outro desenvolvedor utilizando o
Intercâmbio de Projetos serão compatíveis para compartilhamento com a
V5.1.x desde que você não execute nenhuma das
ações a seguir:
- Alterar os metadados de compatibilidade incluídos no arquivo
.project e no arquivo
.compatiblity criados pela ferramenta de migração.
- Excluir o arquivo
.compatibility desses projetos.
Um arquivo
.compatibility é criado automaticamente no diretório project
quando um projeto V5.1.x é aberto no espaço de trabalho do
Rational Web Developer V6.0. O arquivo
.compatibility é utilizado pelo Rational Web Developer para rastrear
os timestamps dos recursos do projeto quando esses recursos são
migrados. Você não deve editá-lo ou excluí-lo.
Para obter informações sobre como desativar a compatibilidade com o
WebSphere Studio Site Developer V5.1.x, consulte Desativando a Compatibilidade com o WebSphere Studio V5.1.x.
Considerações do Eclipse
Esta versão do Rational Web Developer é baseada no Eclipse
V3.0. Se você desenvolver seus próprios plug-ins, você
deve ler sobre alterações da plataforma antes de migrar.
Para obter detalhes, consulte o arquivo leia-me no
subdiretório eclipse\readme do local da instalação do Rational Web
Developer V6.0. As seções do arquivo leia-me que são
interessantes para a migração são:
- Compatibilidade com Releases Anteriores
- Fazendo Upgrade do Espaço de Trabalho a partir de um Release Anterior
- Interoperabilidade com Releases Anteriores
Compatibilidade do Projeto do J2EE
A compatibilidade com releases futuros de projetos criados no WebSphere
Studio V5.1.x com o Rational Web Developer V6.0 é
ativada por meio de metadados que são incluídos automaticamente nos
arquivos .project, quando você migrar seu espaço de trabalho
V5.1.x. De forma semelhante, se você criar um novo
módulo ou aplicativo J2EE 1.2 ou 1.3 no Rational Web
Developer V6.0, os metadados da compilação são automaticamente
incluídos no arquivo
.project para compatibilidade com a V5.1.x. Não
edite ou exclua essas informações diretamente.
- Nota:
- Esses metadados de compatibilidade farão com que mensagens sobre
"construtores ausentes" sejam exibidas ou registradas quando um novo módulo
ou aplicativo J2EE 1.2 e J2EE 1.3 criado na V6.0 for
utilizado no WebSphere Studio Site Developer V5.1.X, onde os
construtores V6.0 não estão disponíveis. Essas
mensagens são normais; você pode ignorá-las.
Desde que esses metadados de compatibilidade estejam presentes, serão
exibidas mensagens sobre "construtores ausentes" quando projetos do Rational
Web Developer V6.0 forem carregados no WebSphere Studio
V5.1.x. Segue um exemplo de uma mensagem de "construtor
ausente":
!ENTRY org.eclipse.core.resources 2 1 Sep 06, 2004 19:55:20.592
!MESSAGE Ignorando construtor com.ibm.wtp.j2ee.LibCopyBuilder para projeto Test60EARWeb.
O construtor está faltando na instalação ou pertence a uma natureza de projeto
ausente ou desativada.
Essas mensagens são normais; você pode ignorá-las.
Quando você tiver certeza de que não precisa mais trabalhar com um
determinado projeto no WebSphere Studio V5.1.x, é possível
parar as mensagens,
desativando a compatibilidade
com releases anteriores para o projeto.
Importante: Novos projetos de especificação J2EE
1.2 ou 1.3 criados na V6.0 são compatíveis com o
WebSphere Studio V5.1.x, mas depois do projeto ser carregado no
WebSphere Studio, há algumas etapas manuais necessárias antes de você
poder trabalhar com o projeto. Essas etapas são necessárias
porque os destinos do tempo de execução em novos projetos de
especificação J2EE 1.2 ou 1.3 criados na 6.0 não
são diretamente compatíveis com releases anteriores dos servidores de
destino na V5.1.x. As etapas manuais após o
carregamento de um novo projeto V6.0 na V5.1.x são as
seguintes:
- Abra o arquivo .classpath para cada projeto do J2EE que
tem um arquivo .classpath.
- Exclua as seguintes entradas do caminho de classe do arquivo
.classpath, salve e feche o arquivo.
-
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/
org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere v5.1 JRE"/>
-
<classpathentry kind="con"
path="com.ibm.wtp.server.java.core.container/
com.ibm.etools.websphere.runtime.core.runtimeTarget.v51/was.base.v51"/>
- Certifique-se de que o suporte ao destino esteja ativado na página de
preferências do J2EE. Selecione Janela ->
Preferências -> J2EE e confirme que Ativar
Suporte de Destino do Servidor esteja selecionado em "Suporte de Destino
do Servidor".
- Clique com o botão direito do mouse e selecione Propriedades
-> J2EE.
- Selecione o servidor de destino correspondente para o destino do tempo de
execução no projeto (por exemplo, WebSphere Application Server
V5.1 utilizando o ambiente do tempo de execução do JDK
1.4) e clique em OK.
- O servidor de destino selecionado será compatível com o Rational Web
Developer V6.0 e o WebSphere Studio Site Developer
V5.1.x. Depois das alterações serem consolidadas no
sistema SCM, os projetos do J2EE podem interoperar entre a
V5.1.x e a V6.0, utilizando um sistema SCM.
- Nota:
- Se o servidor de destino for definido novamente no Rational Web Developer
V6.0, a compatibilidade do projeto do J2EE será perdida e
precisará ser restabelecida.
A compatibilidade com o WebSphere Studio Site Developer
V5.1.x pode ser totalmente removida de um projeto do aplicativo
corporativo criado no Rational Web Developer V6.0 ou de um projeto do
aplicativo corporativo migrado de uma versão anterior do WebSphere
Studio. Você deve desativar a compatibilidade com o WebSphere Studio
V5.1.x, somente se tiver certeza de que o projeto do aplicativo
corporativo não deve mais interoperar ou ser compatível com a
V5.1.x.
Para remover a compatibilidade com WebSphere Studio Site Developer
V5.1.x:
- Clique com o botão direito em um projeto do aplicativo corporativo e
selecione a opção de menu Remover Compatibilidade no
pop-up.
- Um diálogo solicitará a confirmação da remoção da
compatibilidade com releases anteriores do projeto do aplicativo corporativo e
de todos os módulos e projetos de utilitários aninhados sob o
projeto.
- Clique em Sim para continuar com a operação Remover
Compatibilidade.
Depois da operação Remover Compatibilidade ser executada, o projeto
do aplicativo corporativo e todos os projetos de módulos e utilitários
aninhados sob o projeto do aplicativo corporativo não serão mais
compatíveis com releases anteriores com o WebSphere Studio Site Developer
V5.1.x.
Os recursos de tempo de execução JavaServer Faces fornecidos,
originalmente, no WebSphere Studio Site Developer V5.1.x foram
atualizado para Rational Web Developer V6.0.1. Se você
quiser continuar o desenvolvimento em projetos da Web criados com essa
versão anterior do produto, recomendamos a atualização dos recursos
de tempo de execução Faces para os níveis mais recentes.
No Rational Web Developer V6.0.1, as atualizações dos
recursos de tempo de execução Faces ocorrem automaticamente quando um
projeto da Web é importado ou um espaço de trabalho, que contém
recursos desatualizados, é aberto. Depois de importar um projeto da
Web ou abrir um espaço de trabalho do WebSphere Studio Site Developer
V5.1.x no Rational Web Developer V6.0.1, você
receberá um aviso para atualizar os recursos de tempo de execução
Faces para os níveis mais recentes.
Atualizando automaticamente os recursos de tempo de
execução
Para atualizar os recursos de tempo de execução
automaticamente para um projeto da Web:
- Importe um projeto da Web (ou um espaço de trabalho) com conteúdo do
Faces do WebSphere Studio Site Developer V5.1.x. A janela
Project Migration (Migração de Projetos) é aberta.
- Nota:
- Se a janela Project Migration (Migração de Projetos) não for aberta,
sua configuração de preferência automática de construção
será provavelmente desativada. No Explorer do Projeto, clique com o
botão direito do mouse no projeto da Web e selecione Build
(Construir) -> Project (Projeto); o processo de
reconstrução de um projeto é aberto na janela Project Migration
(Migração de Projetos).
- Se você tiver outros projetos da Web com conteúdo do Faces no
espaço de trabalho, marque Apply this choice to any other projects
that need to be upgraded (Aplicar essa opção a todos os projetos dos
quais é preciso fazer upgrade) para que todos os projetos da Web
sejam atualizados.
- Clique em um dos seguintes:
- Yes (Sim) para concluir a atualização
automaticamente.
- Later (Mais Tarde) para adiar a atualização. Para
atualizar os recursos de tempo de execução automaticamente depois de
selecionar Later (Mais Tarde), você deve fechar e reabrir o
projeto da Web ou reiniciar o workbench antes de reconstruir o projeto da
Web. Se você desativou as construções automáticas, clique
com o botão direito do mouse no projeto da Web e selecione Build
Project (Construir Projeto).
- Never (Nunca) para manter os recursos de tempo de
execução no nível anterior. Se você escolher Never
(Nunca) e intencionalmente ficar com os recursos de tempo de
execução do nível anterior, não receberá nenhum outro aviso de
atualização. No futuro, você terá que atualizar os recursos
de tempo de execução manualmente se precisar deles.
- Nota:
- Se você criou Faces JSPs que contêm componentes Faces Client, deverá
atualizar separadamente os recursos do tempo de execução dos componentes
Faces Client para os níveis mais recentes. Consulte Atualizando Recursos de Tempo de Execução Faces Client em um Projeto da Web.
Atualizando manualmente os recursos de tempo de execução
Para atualizar os recursos de tempo de execução Faces
manualmente para um projeto da Web:
- Importe seu projeto da Web existente com o conteúdo do Faces para um
espaço de trabalho do Rational Web Developer V6.0.1.
- Crie um novo projeto da Web (ou, se você estiver trabalhando com o EGL,
crie um novo projeto da Web EGL) chamado JSF601. Você
utilizará esse projeto somente como uma origem para os recursos de tempo de
execução mais recentes; ele pode ser excluído após a
conclusão da atualização.
- No Explorer do Projeto, clique com o botão direito do mouse no projeto
JSF601 e selecione Properties (Propriedades) no
menu.
- Clique em Web Project Features (Recursos do Projeto da Web) e
selecione Add Faces Base Components (Incluir Componentes Básico do
Face) e Add Faces Client Framework (Incluir Estrutura do Face
Client) e, em seguida, clique em OK.
- Se você estiver trabalhando com EGL, crie um arquivo de
páginas JSF da seguinte forma:
- Clique com o botão direito do mouse na pasta WebContent de seu novo
projeto da Web EGL.
- Selecione Novo -> Outro -> Arquivo
Faces JSP.
Os arquivos eglintdebug.jar e
eglintdebugsupport.jar são incluídos no
projeto.
- Para cada projeto Faces existente que deseja atualizar, faça o
seguinte:
- No Explorer do Projeto, expanda um projeto existente para mostrar os
arquivos na pasta WebContent/WEB-INF/lib/. Localize e exclua quaisquer
dos seguintes arquivos JAR neste diretório:
- eglintdebug.jar (apenas EGL)
- eglintdebugsupport.jar (apenas EGL)
- fda.jar (apenas EGL)
- fdaj.jar (apenas EGL)
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- odc-jsf.jar
- Localize e abra o arquivo
WebContent/WEB-INF/faces-config.xml. Inclua os seguintes
elementos nesse arquivo de configuração se ainda não estiverem
presentes:
<lifecycle>
<phase-listener>com.ibm.faces.webapp.ValueResourcePhaseListener</phase-listener>
</lifecycle>
<application>
<variable-resolver>com.ibm.faces.databind.SelectItemsVarResolver</variable-resolver>
<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
</application>
- Para qualquer arquivo JAR excluído, copie o arquivo JAR de mesmo nome
do diretório WebContent/WEB-INF/lib do projeto JSF601 e cole-o
no projeto original no mesmo local. Algumas configurações não
exigem que todos esses arquivos JAR estejam presentes no projeto; não
copie um determinado arquivo JAR se ele não estiver no projeto
original.
- Abra o descritor de implementação web.xml no projeto original
e inclua o seguinte na configuração:
<context-param>
<param-name>com.ibm.ws.jsf.JSP_UPDATE_CHECK</param-name>
<param-value>true</param-value>
</context-param> <context-param>
<param-name>com.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP</param-name>
<param-value>true</param-value>
</context-param>
- Se o projeto original utilizou o WDO (WebSphere Data Objects) para
qualquer acesso aos dados, execute as seguintes etapas adicionais:
- No projeto original, clique em File (Arquivo) -> New
(Novo) -> Faces JSP File (Arquivo do Faces JSP) para
criar um novo arquivo Faces JSP temporário.
- Arraste um componente da lista de registros relacionais da gaveta Dados na
paleta para a página.
- Escolha qualquer conexão e origem de dados e clique em Finish
(Concluir). Os dados selecionados não são
importantes. Esse processo gerará qualquer configuração
necessária para continuar utilizando o WDO neste projeto.
- Exclua o arquivo JSP temporário.
- Se você estiver trabalhando com EGL, clique com o botão
direito do mouse no nome de cada projeto da Web EGL e clique em
Gerar; em seguida, se você não estiver construindo os
projetos automaticamente, clique em Projeto -> Construir
Tudo.
- Exclua o projeto da Web JSF601.
Os recursos de tempo de execução JavaServer Faces Client fornecidos
originalmente no WebSphere Studio Site Developer V5.1.x foram
atualizado para o Rational Web Developer V6.0.1. Se
você quiser continuar o desenvolvimento em projetos da Web criados com essa
versão anterior do produto, recomendamos a atualização dos recursos
de tempo de execução Faces Client para os níveis mais
recentes.
No Rational Web Developer V6.0.1, as atualizações dos
recursos de tempo de execução Faces Client ocorrem automaticamente
quando um projeto da Web é importado ou um espaço de trabalho, que
contém recursos desatualizados, é aberto. Depois de importar um
projeto da Web ou abrir um espaço de trabalho do WebSphere Studio Site
Developer V5.1.x Rational Web Developer V6.0.1,
você receberá um aviso para atualizar os recursos de tempo de
execução Faces Client para os níveis mais recentes.
Atualizando automaticamente os recursos de tempo de
execução
Para atualizar os recursos de tempo de execução Faces Client
automaticamente para um projeto da Web:
- Importe um projeto da Web (ou um espaço de trabalho) com conteúdo do
Faces Client do WebSphere Studio Site Developer V5.1.x. A
janela Project Migration (Migração de Projetos) é aberta.
- Nota:
- Se a janela Project Migration (Migração de Projetos) não for aberta,
sua configuração de preferência automática de construção
será provavelmente desativada. No Explorer do Projeto, clique com o
botão direito do mouse no projeto da Web e selecione Build
(Construir) -> Project (Projeto); o processo de
reconstrução de um projeto é aberto na janela Project Migration
(Migração de Projetos).
- Se você tiver outros projetos da Web com conteúdo do Faces Client no
espaço de trabalho, marque Apply this choice to any other projects
that need to be upgraded (Aplicar essa opção a todos os projetos dos
quais é preciso fazer upgrade) para que todos os projetos da Web
sejam atualizados.
- Clique em um dos seguintes:
- Yes (Sim) para concluir a atualização
automaticamente.
- Later (Mais Tarde) para adiar a atualização. Para
atualizar os recursos de tempo de execução automaticamente depois de
selecionar Later (Mais Tarde), você deve fechar e reabrir o
projeto da Web ou reiniciar o workbench antes de reconstruir o projeto da
Web. Se você desativou as construções automáticas, clique
com o botão direito do mouse no projeto da Web e selecione Build
Project (Construir Projeto).
- Never (Nunca) para manter os recursos de tempo de
execução no nível anterior. Se você escolher Never
(Nunca) e intencionalmente ficar com os recursos de tempo de
execução do nível anterior, não receberá nenhum outro aviso de
atualização. No futuro, você terá que atualizar os recursos
de tempo de execução manualmente se precisar deles.
- Na pasta Java Resources (Recursos Java) ->
JavaSource no projeto da Web, exclua todos os pacotes de classe
mediadores de dados do cliente com a convenção de nomenclatura
com.ibm.dynwdo4jsmediators.<client-data-name>.
Não exclua o pacote chamado
com.ibm.dynwdo4jsmediators. Esse pacote contém
metadados (arquivos ecore e emap) para os dados do clientes no seu projeto que
serão utilizados para gerar novamente os mediadores.
- Na pasta Java Resources (Recursos Java) ->
JavaSource no projeto da Web, abra o arquivo
OdysseyBrowserFramework.properties e exclua as entradas para
EMAP_FILES e ECORE_FILES.
- Para cada objeto de dados na visualização Dados do Cliente:
- Clique com o botão direito do mouse e selecione Configure
(Configurar).
- Na guia Advanced (Avançado), clique em Regenerate from
server-side data (Gerar novamente a partir dos dados do lado do
servidor) para gerar novamente todos os mediadores para o objeto de
dados.
Atualizando manualmente os recursos de tempo de execução
Para atualizar os recursos de tempo de execução Faces Client
manualmente para um projeto da Web:
- Conclua as etapas Atualizando Manualmente Recursos de Tempo de
Execução em Atualizando Recursos de Tempo de Execução Faces em um Projeto da Web.
- Conclua as etapas de 4 a 6 da seção Atualizando Automaticamente
os Recursos de Tempo de Execução acima.
Podem ocorrer problemas durante a alteração do servidor de
destino de um projeto contendo componentes Faces Client do WebSphere
Application Server V5.1 para o V6.0.
Há dois problemas que podem ocorrer durante a alteração do
servidor de destino de um projeto contendo componentes Faces Client do
WebSphere Application Server V5.1 para o V6.0:
- As classes de mediadores de dados do cliente que já foram geradas
não serão mais compiladas. Elas precisam ser geradas novamente em
um JSP por vez:
- Abra o arquivo OdysseyBrowserFramework.properties localizado na
pasta de origem Java da raiz. Salve o conteúdo para uso
futuro.
- No arquivo OdysseyBrowserFramework.properties, para cada JSP no
projeto da Web contendo dados do Faces Client, localize as entradas
<client-data-name>.ecore e <client-data-name>.emap
para as propriedades EMAP_FILES e ECORE_FILES.
- Mantenha apenas as entradas correspondentes para os dados do cliente no
JSP e exclua todas as outras entradas.
Por exemplo, se a página atual tiver Dados de Cliente denominados
ACCOUNT e seu arquivo de propriedades tiver uma entrada como:
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap com\\ibm\\dynwdo4jsmediators/orders.emap
você deverá excluir
com\\ibm\\dynwdo4jsmediators/orders.emap da entrada.
A entrada seria agora semelhante a esta:
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap
- Salve o arquivo de propriedades.
- Selecione um objeto de dados do cliente em um JSP e, em seguida, clique
com o botão direito do mouse e selecione Configure
(Configurar).
- Na guia Advanced (Avançado), clique em Regenerate All
(Gerar Tudo Novamente). Isso irá gerar novamente todos os
artefatos necessários para todos os dados do cliente no JSP atual.
- Repita as etapas de 2 a 6 para cada JSP contendo dados do cliente no seu
projeto da Web.
- Depois de gerar novamente as classes de mediadores de dados do cliente,
ainda haverá algumas classes de mediadores que não serão
compiladas. Esses são os mediadores para elementos do esquema não
mais utilizados nos SDOs (Service Data Objects) no V6.x e têm a
convenção de nomenclatura *_DataGraphSchema_wdo4js_*.java e
*_RootDataObject_wdo4js_*.java. Exclua essas classes de
mediadores do projeto da Web para evitar esses erros de
compilação.
- Após a conclusão bem-sucedida da atualização, restaure o
conteúdo original do arquivo
OdysseyBrowserFramework.properties.
- Os componentes Faces Client da visualização em Árvore ligados aos
WDOs falham ao serem executados no servidor após a alteração do
servidor de destino do projeto para WebSphere Application Server
V6.0. A solução alternativa é modificar a
visualização de origem do JSP para alterar todas as tags className para
utilizar a classe DataObject do SDO em vez da classe DataObject do WDO.
Por exemplo, para um WDO chamado account:
- Para o objeto raiz, altere a tag className de
className="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)"
para
className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)".
- Para todos os nós-filho, altere a tag className de
className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)"
para
className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)",
em que ACCOUNT é o nome do nó de dados.
Fazendo Upgrade para processadores e rotinas de tratamento Diff
automatizados
Os processadores e as rotinas de tratamento Diff agora são geradas
automaticamente. Se você gravou rotinas de tratamento e
processadores Diff para os componentes Faces Client no WebSphere Studio
V5.1.x, recomendamos descartar aquele código e utilizar os
processadores e as rotinas de tratamento gerados automaticamente:
- Gere os novos processadores e rotinas de tratamento Diff em cada objeto de
dados do cliente no projeto da Web.
- Selecione o objeto de dados do cliente, clique com o botão direito do
mouse e selecione Configure (Configurar).
- Na guia Advanced (Avançado), clique em Regenerate All
(Gerar Tudo Novamente).
- Remova o código gravado para chamar o processador e as rotinas de
tratamento Diff, pois os processadores e as rotinas de tratamento gerados
são chamados automaticamente. Um exemplo típico de onde esse
código era utilizado seria no evento Comando para o componente Botão de
comandos, como:
String Diff = getClientData1().getDiffStr();
if (DiffProcessor.Synch(getRoot(), Diff) == true)
return "";
return "failure";
- Remove os arquivos correspondentes às rotinas de tratamento e aos
processadores personalizados antigos criados no projeto da Web.
Mantendo os processadores e as rotinas de tratamento personalizados
gravados para V5.1.x
Embora isso não seja recomendados, se você decidir que precisa manter
as rotinas de tratamento e os processadores Diff do V5.1.x, eles
deverão ser modificados para funcionarem no V6.0, à medida que a
interface DiffHandler e a classe DiffInfo class é alterada.
- A interface DiffHandler foi alterada da seguinte forma:
- O método handle agora emite Exception, além de DiffException.
- O novo método find é utilizado pela estrutura para localizar
objetos.
- O novo método getId é utilizado para depuração e permite que a
estrutura imprima o valor de um objeto.
Os métodos find e getId são utilizados internamente pelos
DiffHandlers gerados. Para seus DiffHandlers personalizados, você
pode implementar métodos vazios simplesmente para obter conformidade com a
interface. Esses métodos não serão chamados pela
estrutura.
A interface DiffHandler é agora:
public interface DiffHandler
{
public void handle(DiffInfo Diff) throws DiffException, Exception;
public Object find (DiffInfo Diff) throws DiffException, Exception;
public String getId (DiffInfo Diff, boolean Original);
}
- A classe DiffInfo foi alterada da seguinte forma:
- O método ArrayList getAncestors() foi substituído pelo método
DiffInfo getParent(), que oferece uma maneira mais fácil de acessar as
informações de cada objeto na árvore de ascendentes de um modo
recursivo.
- Os métodos getCurrent() e getOriginal() agora retornam um objeto
DataObject em vez de um objeto EObject. Não é obrigatório
alterar o código para utilizar o objeto DataObject. Entretanto, a
interface DataObject é muito mais fácil e mais intuitiva para ser
utilizada que EObject. Você pode converter facilmente um objeto
DataObject para um objeto EObject para o código existente.
- Um novo método String getPropertyName() foi incluído para
identificar o nome da propriedade à qual esse objeto se aplica. Isso
será importante se, por exemplo, uma determinada classe tiver duas
propriedades do mesmo tipo. Anteriormente na classe DiffInfo, o
código não conseguiria diferenciar entre as duas propriedades.
A classe DiffInfo é agora:
public class DiffInfo
{
public char getCrud()
public DataObject getCurrent()
public String getEClassName()
public DataObject getOriginal()
public String getPropertyName()
public DiffInfo getParent()
}
- Nota:
- A classe DiffInfo não é mais suportada para utilização pública
porque agora os processadores e rotinas de tratamento Diff são gerados
automaticamente. Manter suas rotinas de tratamento antigas é uma
solução apenas temporária e é bastante recomendável que as
rotinas de tratamento automatizadas sejam utilizadas.
Alterações nos componentes Faces Client no V6.0
- Suporte para o WebSphere Application Server V6.0.
- Suporte para o SDO (Service Data Objects) no WebSphere Application Server
V6.0.
- Os dados EGL são agora suportados como dados de cliente.
- Os processadores e rotinas de tratamento Diff são gerados
automaticamente.
- Há novos eventos nos seguintes componentes:
- TabbedPanel: onInitialPageShow
- Árvore: onNodeExpand, onNodeCollapse, onExpand, onCollapse
- DataGrid: onPage, onSort, onFilter
Para projetos da Web Struts criados no WebSphere Studio
V5.1.x, você deve fazer uma pequena modificação no
descritor de implementação do projeto da Web para executar o projeto EAR
no WebSphere Application Server V6.0. Também é possível
converter manualmente projetos da Web Struts 1.0.2 ou Struts
1.1 Beta (2 ou 3) existentes para Struts 1.1.
Modificando o descritor de implementação de projetos da Web
Struts existentes
Quando um projeto Struts é criado no WebSphere Studio v5.x, o
parâmetro de configuração
(<param-name>config</param-name>) no descritor de
implementação do projeto da Web é definido para
WEB-INF/struts-config.xml. O WebSphere Application Server
V6.0 exige que uma barra "/" esteja presente nesse parâmetro.
Se você executar um projeto da Web Struts, criado no WebSphere Studio
V5.1.x, no WebSphere Application Server V6.0, poderá
receber uma exceção java.net.MalformedURLException ao
iniciar o projeto EAR.
- Nota:
- O Rational Web Developer V6.0 incluirá a "/" quando um novo projeto
Struts for criado; contudo, ela deve ser incluída manualmente durante
a migração do WebSphere Studio V5.1x.
Siga estas etapas para corrigir, no V6.0, o descritor de
implementação de um projeto da Web Struts criado no WebSphere Studio
v5.1.x:
- Abra o projeto da Web Struts no Explorer do Projeto.
- Dê um clique duplo no arquivo Deployment Descriptor (Descritor de
Implementação) do projeto da Web no Explorer do Projeto. O
editor do descritor de implementação é aberto.
- Clique na guia Source (Origem) para abrir a página Source
(Origem).
- Altere a linha
<param-value>WEB-INF/struts-config.xml</param-value>
(ela está localizada dentro das tags
<servlet></servlet>)
para
<param-value>/WEB-INF/struts-config.xml</param-value>
.
- Salve o Descritor de Implementação.
A exceção java.net.MalformedURLException não deve
ocorrer quando o projeto EAR for reiniciado.
Convertendo Projetos da Web do Struts 1.1 Beta para Struts
1.1
No WebSphere Studio V5.1.x, a biblioteca de tempo de
execução Struts possui etapas do Struts 1.1 Beta (2 ou 3) no
V5.0.x para o Struts 1.1 (final). Se você tiver
projetos da Web Struts 1.1 Beta (2 ou 3) existentes e quiser
convertê-los para Struts 1.1 (final), deverá fazê-lo
manualmente. (Nota: não é necessário
converter projetos Struts 1.1 Beta (2 ou 3) para Struts
1.1. )
Para converter projetos Struts 1.1 Beta (2 ou 3) para Struts
1.1, faça o seguinte:
- Carregue os projetos Struts 1.1 Beta em um espaço de trabalho do
Rational Web Developer V6.0.
- Crie um novo projeto da Web Struts 1.1 chamado, por exemplo, de
Struts11. Você cria esse projeto temporário para
fornecer acesso conveniente aos arquivos de tempo de execução do Struts
1.1 necessário enquanto você estiver convertendo seus projetos
reais. Você pode excluir esse projeto quando tiver
concluído.
- Para cada projeto Struts 1.1 Beta que deseja converter para Struts
1.1, faça o seguinte:
- Exclua os seguintes arquivos JAR do diretório Content/WEB-INF/lib da
Web do projeto:
- commons-*.jar.
- struts.jar.
- Copie os seguintes arquivos JAR do diretório
Struts11/WebContent/WEB-INF/lib para o diretório Content/WEB-INF/lib da Web
do projeto:
- commons-*.jar.
- struts.jar.
- Exclua os seguintes arquivos do TLD (Tag Library Descriptor) do
diretório Content/WEB-INF da Web do projeto:
struts-*.tld.
- Copie os seguintes arquivos TLD do diretório
Struts11/WebContent/WEB-INF para o diretório Content/WEB-INF da Web do
projeto: struts-*.tld.
Convertendo Projetos da Web do Struts 1.0.2 para o
Struts 1.1
No WebSphere Studio V5.1.x (and V5.0.x), ao
incluir suporte de Struts em um projeto da Web você tinha a opção de
escolher Struts 1.0.2. Se você tiver projetos da Web
Struts 1.0.2 existentes e quiser convertê-los para Struts
1.1, será necessário fazê-lo manualmente.
(Nota: não é necessário converter projetos Struts
1.1 Beta (2 ou 3) para Struts 1.1. )
Para converter projetos Struts 1.0.2 para Struts 1.1,
faça o seguinte:
- Carregue os projetos Struts 1.0.2 em um espaço de
trabalho Rational Web Developer V6.0.
- Crie um novo projeto da Web Struts 1.1 chamado, por exemplo, de
Struts11. Você cria esse projeto temporário para
fornecer acesso conveniente aos arquivos de tempo de execução do Struts
1.1 necessário enquanto você estiver convertendo seus projetos
reais. Você pode excluir esse projeto quando tiver
concluído.
- Para cada projeto Struts 1.0.2 que deseja converter para
Struts 1.1, faça o seguinte:
- Exclua o arquivo struts.jar do diretório Content/WEB-INF/lib da
Web do projeto.
- Copie os seguintes arquivos JAR do diretório
Struts11/WebContent/WEB-INF/lib para o diretório Content/WEB-INF/lib da Web
de projeto:
- commons-*.jar.
- struts.jar.
- jarkarta-oro.jar.
- Exclua os seguintes arquivos do TLD (Tag Library Descriptor) do
diretório Content/WEB-INF da Web do projeto:
struts-*.tld.
- Copie os seguintes arquivos TLD do diretório
Struts11/WebContent/WEB-INF para o diretório Content/WEB-INF da Web do
projeto: struts-*.tld.
Há várias alterações nas ferramentas de depuração no
Rational Web Developer V6.0. Você precisará estar ciente
dessas alterações, para utilizar essas ferramentas com seus projetos
depois da migração. Pode ser necessário alterar ou restaurar
as configurações.
Migrando Espaços de Trabalho e Configurações de
Ativação
Quando um espaço de trabalho V5.1.x do WebSphere Studio
Site Developer é aberto no Rational Web Developer V6.0, as seguintes
configurações de ativação do depurador associadas ao espaço de
trabalho não serão migradas automaticamente:
- Depurar no Servidor: As configurações de
ativação criadas anteriormente através da ação Depurar no
Servidor, não serão migradas para a V6.0. Para ativar um
aplicativo para depuração em um servidor na V6.0, selecione o
aplicativo novamente e escolha Depurar no Servidor. Isso
criará uma nova configuração de ativação para o
aplicativo.
- Conexão do Servidor: As configurações de
ativação de depuração do WebSphere Application Server
criadas anteriormente para uma conexão do servidor não migrarão para
a V6.0. A configuração de ativação de
depuração do WebSphere Application Server não existe mais.
Para executar uma conexão de servidor para depuração na V6.0,
utilize a ação Depurar no Servidor e crie um WebSphere V5
Server Attach para 5.x ou um WebSphere V6.0 Server Attach para
6.0.
- Depurador de SQLJ: A configuração da ativação
de depuração de SQLJ não existe mais e as configurações de
ativação de SQLJ anteriormente criadas não migrarão para a
V6.0. Para ativar programas SQLJ para depuração na
V6.0, utilize a configuração de ativação do Aplicativo
Java.
- Depurador do Procedimento Armazenado: As
configurações de ativação do depurador do procedimento armazenado
criadas anteriormente serão migradas para o Rational Web Developer
V6.0 e estarão disponíveis para utilização na caixa de
diálogo Depurar Configurações de Ativação.
Depois da migração, se você utilizar a ação Depurar
no menu pop-up Visualização da Definição de Dados, uma
nova configuração de ativação será criada para você.
- Nota:
- Se você migrar um espaço de trabalho que contenha um procedimento
armazenado e, em seguida, reconstruir o procedimento armazenado para
depuração, as configurações de ativação migradas associadas
ao procedimento armazenado não funcionarão.
- Depurador EGL: Depois de migrar um espaço de trabalho,
as etapas a seguir devem ser executadas para as configurações de
ativação do depurador EGL:
- Modifique o JRE (Java Runtime Environment) instalado para apontar para o
local correto. Depois de migrar um espaço de trabalho, seu JRE
instalado apontará para o JRE a partir da versão anterior do WebSphere
Studio Site Developer. Para alterar isso, aponte para o novo local do
JRE da seguinte forma:
- Selecione Janela -> Preferências a partir
do menu do workbench.
- No diálogo Preferências resultante, expanda o nó Java
e, em seguida, selecione o nó JREs Instalados.
- No lado direito, defina o JRE instalado para apontar para o que foi
instalado com a versão atual desse produto. O local do JRE é o
subdiretório \eclipse\jre do diretório de instalação do Rational
Web Developer V6.0.
- Na configuração de ativação, selecione a guia
Origem antes da ativação (não fazer isso resultará em
um erro de "origem não localizada"). Se você tiver incluído
locais de origens na configuração de ativação no espaço de
trabalho V5.1.x, você precisará incluir manualmente esses
locais novamente na configuração de ativação migrada.
- Depurador de Linguagem Compilada: Depois de migrar um
espaço de trabalho, as etapas a seguir precisam ser executadas para as
configurações de ativação do depurador de linguagem compilada
existente:
- Se você tiver definido variáveis de ambiente na guia Ambiente
do Sistema da configuração de ativação do Aplicativo
Compilado, será necessário incluí-las novamente manualmente na
configuração de ativação migrada.
- Se você tiver incluído locais de origem nas configuração de
ativação de Aplicativo Compilado ou de Conectar a um
Processo em Execução, será necessário incluí-los
novamente manualmente na configuração de ativação migrada.
Depurar Visualizações
As visualizações Armazenamento e Mapeamento do Armazenamento não
existem mais. Elas foram substituídas pelas visualizações
Memória e Apresentação de Memória.
O Depurador XSLT
Esse depurador foi substituído na V6.0 e muitas de suas
visualizações e ações foram alteradas de forma
significativa. Para obter informações adicionais, consulte a
documentação do depurador XSLT no centro de informações.
Uma das alterações mais significativas no depurador XSLT é sua
dependência no JRE instalado com o Rational Web Developer
V6.0. Se você migrar um espaço de trabalho do WebSphere
Studio Site Developer V5.1.x, será necessário modificar o
JRE instalado para apontar para o local correto antes de poder ativar uma
sessão de depuração XSLT para ele. Para fazer isso, é
possível executar uma das seguintes ações:
- Alterar o JRE para todo o espaço de trabalho, apontando-o para o novo
local do JRE, executando as seguintes etapas:
- Selecione Janela -> Preferências a partir
do menu do workbench.
- Na janela Preferências, expanda o nó Java e, em seguida,
selecione o nó JREs Instalados.
- No lado direito, defina o JRE instalado para apontar para o que foi
instalado com a versão atual desse produto. O local do JRE é o
subdiretório \eclipse\jre do diretório de instalação do Rational
Web Developer V6.0.
- Se você tem a intenção de ativar a sessão de depuração
através do diálogo Depurar Configurações de
Ativação, é possível alterar o JRE da configuração de
ativação, apontando-o para o novo local do JRE. Para fazer isso,
abra a configuração de ativação na caixa de diálogo
Depurar Configurações de Ativação. Selecione a
guia JRE e especifique o novo local do JRE no campo JRE
Alternativo.
Se você tiver criado código em um projeto da Web tendo como destino o
WebSphere Application Server V5.1 que utilizou registros relacionais ou
listas de registros relacionais WDO (WebSphere Data Objects), ao ter como
destino o WebSphere Application Server V6.0 para esses aplicativos,
você deverá utilizar registros relacionais e listas de registros
relacionais SDO (Service Data Objects). A migração do WDO para o
SDO ocorre automaticamente quando você alterar o servidor de destino de seu
aplicativo do WebSphere Application Server V5.1 para o WebSphere
Application Server V6.0.
O servidor de destino pode ser alterado de duas maneiras:
- É possível modificar o servidor de destino utilizando o diálogo
de propriedades do projeto. Clique com o botão direito do mouse no
projeto na visualização Project Explorer e selecione
Propriedades -> Servidor -> Tempo de
Execução do Destino.
- Durante a migração do J2EE, utilizando o Assistente para
Migração do J2EE, é possível especificar um destino de aplicativo
para utilizar outro servidor.
- Nota:
- É possível migrar somente para um nível de especificação J2EE
mais alto.
Os tópicos de ajuda sobre como alterar seu servidor de destino e sobre
como utilizar o Assistente para Migração do J2EE podem ser encontrados
na ajuda on-line do Rational Web Developer.
Considerações de Compatibilidade
- Qualquer código gravado nas APIs (Application Programming Interfaces)
públicas para os beans de acesso do WDO será suportado na V6.0
(apesar das classes de implementação terem sido alteradas para apontar o
tempo de execução do SDO).
- O novo código gerado para o WebSphere Application Server V6.0
não utilizará os beans de acesso do WDO, mas irá gerar código para
as APIs puras do SDO.
- Qualquer código gerado para um projeto tendo como destino a V6.0
não será executado em um servidor V5.1, mesmo se migrado de
volta, redefinido o servidor de destino.
- Código gravado para a V5.1 pode ser migrado para frente e para
trás tendo como destino um servidor V5.1.
Erros de Conflito de Tipos Podem Ocorrer após a Migração de
WDO para SDO
Depois que um projeto utilizando o WDO for migrado para um projeto baseado
em SDO, se você incluir dados SDO em uma página JSP existente que tenha
dados WDO existentes, poderão ocorrer erros de conflito de tipos.
Isso ocorre devido à mistura de beans de acesso existentes do WDO e APIs
independentes do SDO. Por exemplo, você poderá ver um erro de
compilação no arquivo de origem Java do JSP semelhante ao
seguinte:
A importação de com.ibm.websphere.sdo.mediator.exception.MediatorException é conflitante com um outro tipo importado
Esses erros de conflito de tipos podem ser corrigidos da seguinte
forma:
- Remova a instrução de importação conflitante do arquivo de
origem Java. Utilizando o exemplo anterior, você removeria a
seguinte instrução de importação do arquivo de origem:
import com.ibm.websphere.wdo.mediator.exception.MediatorException;
- Modifique o arquivo de origem Java que referencia esse tipo para utilizar
o nome completo da classe. Com base no exemplo acima, o tipo
MediatorException deve ser alterado para
com.ibm.websphere.wdo.mediator.exception.MediatorException.
Por exemplo, o código fonte gravado como
catch ( MediatorException e1 ) {
deve ser alterado para
catch
( com.ibm.websphere.wdo.mediator.exception.MediatorException e1 ) {
Alterações de um Projeto da Web Depois de Alterar o Servidor de
Destino da V5.1 para a V6.0 (WDO para SDO)
As alterações a seguir são feitas automaticamente quando o
servidor de destino é alterado da V5.1 para V6.0:
- Os arquivos JARs (Java archive) wdo_web.jar e
wdo_jdbc_access.jar são removidos do projeto.
- Os arquivos JARs a seguir são removidos do caminho de classe do
projeto:
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- Os arquivos sdo_web.jar e sdo_access_beans.jar são
incluídos no projeto (os arquivos JAR do tempo de execução do SDO
são automaticamente incluídos em algum caminho de classe do projeto
V6.0).
- Todos os arquivos JARs da JSTL (JavaServer Pages Standard Tag Library)
são removidos do projeto. (Os arquivos JARs do JSTL 1.1/JSP
2.0 são automaticamente incluídos em qualquer caminho de classe
do projeto V6.0.)
- As instruções de importação a seguir são alteradas em
qualquer arquivo de origem Java:
- com.ibm.websphere.wdo.access.connections.ConnectionManager
muda para
com.ibm.websphere.sdo.access.connections.ConnectionManager.
- com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper
muda para
com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper.
Alterações de um Projeto da Web Depois de Alterar o Destino do
Servidor da V6.0 para a V5.1 (SDO a WDO)
As alterações a seguir são feitas automaticamente quando o
servidor de destino é alterado da V6.0 para V5.1:
- Os arquivos JARs sdo_web.jar e sdo_access_beans.jar são
removidos do projeto.
- Os arquivos JARs wdo_web.jar e wdo_jdbc_access.jar são
incluídos no projeto.
- Os arquivos JARs a seguir são incluídos no caminho de classe do
projeto:
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- Os arquivos JARs do JSTL 1.0 são incluídos no projeto.
(Os JARs do JSTL 1.1/JSP 2.0 são removidos do caminho de
classe do projeto).
- As instruções de importação a seguir são alteradas em
qualquer arquivo de origem Java:
- com.ibm.websphere.sdo.access.connections.ConnectionManager
torna-se
com.ibm.websphere.wdo.access.connections.ConnectionManager.
- com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper
torna-se
com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper.
Alterações de um Projeto da Web Depois de Alterar o Nível de
J2EE de seu Aplicativo de 1.3 para 1.4
Além das alterações que ocorrem para migrar do WSD para o SDO
alterando o destino do servidor para o WebSphere Application Server
V6.0, alterar o nível de especificação J2EE de seu aplicativo
de 1.3 para 1.4 atualiza todas as referências da biblioteca
de tags (taglib) de suas JSPs (JavaServer Pages) da utilização de WDO,
bibliotecas de tags JSTL 1.0 para SDO, bibliotecas de tags JSTL
1.1/jsp 2.0. A tabela a seguir mostra as alterações
nas referências de taglibs JSP, quando você move do J2EE 1.3 para
J2EE 1.4.
Tabela 1. Referências de Taglibs JSP no J2EE 1.3 e J2EE 1.4.
| Taglib J2EE 1.3 (WDO)
| Taglib J2EE 1.4 (SDO)
|
| http://www.ibm.com/websphere/wdo/core
| http://www.ibm.com/websphere/sdo/core
|
| http://java.sun.com/jstl/core
| http://java.sun.com/jsp/jstl/core
|
| http://java.sun.com/jstl/fmt
| http://java.sun.com/jsp/jstl/fmt
|
| http://java.sun.com/jstl/xml
| http://java.sun.com/jsp/jstl/xml
|
| http://java.sun.com/jstl/sql
| http://java.sun.com/jsp/jstl/sql
|
Há novas palavras reservadas do EGL (Enterprise Generation Language) no
Rational Web Developer.
As novas palavras reservadas estão listadas aqui:
- as
- isa
- like
- matches
- money
- openUI
- ref
- self
- string
- this
Os programas EGL do WebSphere Studio V5.1.x importados e
construídos em um espaço de trabalho V6.0 que utilizam essas
palavras como variáveis ou nomes de partes serão ativados com a seguinte
mensagem: IWN.SYN.2002.e 39/2 Erro de sintaxe
na entrada "variableName". É possível corrigir o problema,
renomeando a variável.
Os recursos de tempo de execução JavaServer Faces e Faces Client
fornecidos originalmente no Rational Web Developer V6.0 foram
atualizados para o Rational Web Developer V6.0.1. Se
você quiser continuar o desenvolvimento em projetos da Web criados com essa
versão anterior do produto, recomendamos a atualização dos recursos
de tempo de execução Faces e Faces Client para os níveis mais
recentes.
No Rational Web Developer V6.0.1, as atualizações dos
recursos de tempo de execução Faces e Faces Client ocorrem
automaticamente quando um projeto da Web é importado ou um espaço de
trabalho, que contém recursos de tempo de execução Faces e Faces
Client desatualizados, é aberto. Depois de importar um projeto da
Web ou abrir um espaço de trabalho do Rational Web Developer V6.0
para o Rational Web Developer V6.0.1, você receberá um
aviso para atualizar esses recursos de tempo de execução para os
níveis mais recentes.
Atualizando automaticamente os recursos de tempo de
execução
Para atualizar os recursos de tempo de execução Faces e Faces Client
automaticamente para um projeto da Web:
- Importe um projeto da Web (ou um espaço de trabalho) com conteúdo do
Faces ou Faces Client do Rational Web Developer V6.0. A janela
Project Migration (Migração de Projetos) é aberta.
- Nota:
- Se a janela Project Migration (Migração de Projetos) não for aberta,
sua configuração de preferência automática de construção
será provavelmente desativada. No Explorer do Projeto, clique com o
botão direito do mouse no projeto da Web e selecione Build
(Construir) -> Project (Projeto); o processo de
reconstrução de um projeto é aberto na janela Project Migration
(Migração de Projetos).
- Se você tiver outros projetos da Web com conteúdo do Face e Faces
Client no espaço de trabalho, marque Apply this choice to any other
projects that need to be upgraded (Aplicar essa opção a todos os
projetos dos quais é preciso fazer upgrade) para que todos os
projetos da Web sejam atualizados.
- Clique em um dos seguintes:
- Yes (Sim) para concluir a atualização
automaticamente.
- Later (Mais Tarde) para adiar a atualização. Para
atualizar os recursos de tempo de execução automaticamente depois de
selecionar Later (Mais Tarde), você deve fechar e reabrir o
projeto da Web ou reiniciar o workbench antes de reconstruir o projeto da
Web. Se você desativou as construções automáticas, clique
com o botão direito do mouse no projeto da Web e selecione Build
Project (Construir Projeto).
- Never (Nunca) para manter os recursos de tempo de
execução no nível anterior. Se você escolher Never
(Nunca) e intencionalmente ficar com os recursos de tempo de
execução do nível anterior, não receberá nenhum outro aviso de
atualização. No futuro, você terá que atualizar os recursos
de tempo de execução manualmente se precisar deles.
Atualizando manualmente os recursos de tempo de execução
Para atualizar os recursos de tempo de execução Faces e Faces Client
manualmente para um projeto da Web:
- Crie um novo projeto da Web (ou, se você estiver trabalhando com o EGL,
crie um novo projeto da Web EGL) chamado JSF601. Você
utilizará esse projeto somente como uma origem para os recursos de tempo de
execução mais recentes; ele pode ser excluído após a
conclusão da atualização.
- No Explorer do Projeto, clique com o botão direito do mouse no projeto
JSF601 e selecione Properties (Propriedades) no
menu.
- Clique em Web Project Features (Recursos do Projeto da Web) e
selecione Add Faces Base Components (Incluir Componentes Básico do
Face) e Add Faces Client Framework (Incluir Estrutura do Face
Client) e, em seguida, clique em OK.
- Se você estiver trabalhando com EGL, crie um arquivo de
páginas JSF da seguinte forma:
- Clique com o botão direito do mouse na pasta WebContent de seu novo
projeto da Web EGL.
- Selecione Novo -> Outro -> Arquivo
Faces JSP.
Os arquivos eglintdebug.jar e
eglintdebugsupport.jar são incluídos no
projeto.
- Para cada projeto Faces existente que deseja atualizar, faça o
seguinte:
- No Explorer do Projeto, expanda um projeto existente para mostrar os
arquivos na pasta WebContent/WEB-INF/lib/. Localize e exclua quaisquer
dos seguintes arquivos JAR neste diretório:
- eglintdebug.jar (apenas EGL)
- eglintdebugsupport.jar (apenas EGL)
- fda6.jar (apenas EGL)
- fdaj6.jar (apenas EGL)
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- odc-jsf.jar
- Para qualquer arquivo JAR excluído, copie o arquivo JAR de mesmo nome
do diretório WebContent/WEB-INF/lib do projeto JSF601 e cole-o
no projeto original no mesmo local. Algumas configurações não
exigem que todos esses arquivos JAR estejam presentes no projeto; não
copie um determinado arquivo JAR se ele não estiver no projeto
original.
- Se você estiver trabalhando com EGL, clique com o botão
direito do mouse no nome de cada projeto da Web EGL e clique em
Gerar; em seguida, se você não estiver construindo os
projetos automaticamente, clique em Projeto -> Construir
Tudo.
- Exclua o projeto da Web JSF601.
O Assistente para Migração do J2EE foi atualizado no Rational Web
Developer V6.0 para migrar projetos do J2EE para o nível de
especificação J2EE 1.4. O Assistente de Migração
J2EE suporta migração das especificações J2EE 1.2 e
1.3 para o nível de especificação J2EE 1.4 para todos
os tipos de módulo J2EE.
Consulte Migração do Nível de Especificação J2EE 1.3 para 1.4 e Migração do Nível de Especificação J2EE 1.2 para 1.4 para obter detalhes sobre a migração
dos artefatos do nível de especificação J2EE 1.3 e 1.2
para o nível de especificação J2EE 1.4.
- Nota:
- Antes de utilizar o Assistente para Migração do J2EE, é altamente
recomendável executar as seguintes etapas:
- Faça o backup de todo seu espaço de trabalho.
- Se estiver trabalhando com um repositório compartilhado, registre
saída ou trave todos os projetos correspondentes.
O Assistente para Migração do J2EE pode ser acessado da seguinte
forma:
- Na visualização Hierarquia J2EE da perspectiva J2EE,
clique com o botão direito do mouse no projeto do aplicativo corporativo
que deseja migrar.
- Selecione Migrar -> Assistente para Migração
do J2EE a partir do menu pop-up.
- Siga as instruções da Página de Boas-vindas do Assistente para
Migração do J2EE antes de prosseguir com o processo de
migração.
Nota:
- A migração dos serviços da Web protegidos (J2EE 1.3 para
1.4) requer migração manual dos arquivos de ligação e
extensão protegidos. Consulte Migrando Serviços da Web Protegidos para obter detalhes.
Consulte a ajuda on-line para obter detalhes completos sobre como utilizar
o Assistente para Migração do J2EE. As alterações para o
assistente estão descritas em Alterações no Assistente para Migração do J2EE no Rational Web Developer V6.0.
Consulte Migração do Nível de Especificação J2EE 1.3 para 1.4 e Migração do Nível de Especificação J2EE 1.2 para 1.4 para obter detalhes sobre a migração
dos artefatos do nível de especificação J2EE 1.3 e 1.2
para J2EE 1.4.
Os serviços da Web protegidos não são migrados pelo Assistente de
Migração do J2EE quando os serviços da Web são migrados de J2EE
1.3 para J2EE 1.4. A migração dos serviços da
Web protegidos requerem etapas manuais.
Após a migração do J2EE, os arquivos de extensão e
ligação protegidos devem ser migrados manualmente para J2EE 1.4
da seguinte maneira:
- Dê um clique duplo no arquivo webservices.xml para abrir o
editor de Serviços da Web.
- Selecione a guia Configurações de Ligações para
editar o arquivo de ligação.
- Inclua todas as configurações de ligação necessárias sob as
novas seções Solicitar Detalhes da Configuração de
Ligação do Consumidor e Detalhes de Configuração de
Ligação do Gerador de Resposta.
- Selecione a guia Extensão para editar o arquivo de
extensões.
- Inclua todas as configurações de extensão necessárias sob as
novas seções Solicitar Detalhes da Configuração de Serviço
do Consumidor e Detalhes de Configuração de Serviço do
Gerador de Resposta.
- Salve e saia do editor.
Os projetos do J2EE podem ser migrados do nível de especificação
J2EE 1.3 para J2EE 1.4. Essa seção descreve, para
cada tipo de projeto J2EE, os artefatos migrados do J2EE 1.3 para J2EE
1.4 pelo Assistente para Migração do J2EE.
Artefatos de um descritor de implementação da Web são migrados
pelo Assistente para Migração do J2EE quando um projeto da Web de
nível de especificação J2EE 1.3 for migrado para o nível de
especificação J2EE 1.4.
Os seguintes artefatos de aplicativos da Web são migrados:
Limitações de Autenticação
O J2EE 1.4 inclui um objeto Description que possui dois
atributos: language e value. Esse objeto
Description não existia no J2EE 1.3; a descrição era um
atributo na Limitação de Autenticação. Portanto, quando os
artefatos de um descritor de implementação da Web são migrados para
J2EE 1.4, o value do objeto Description é obtido do
atributo de descrição da limitação de Autenticação.
Limitações de Segurança
Semelhantemente, no J2EE 1.3 a descrição era um atributo na
Limitação de Segurança. No J2EE 1.4, há um novo
objeto Description com os atributos language e
value. Assim, o value do objeto Description é
obtido do atributo de descrição da Limitação de
Segurança.
Aplicativo da Web
O atributo da cadeia de descrição do objeto ContextParam no nível
de especificação J2EE 1.3 foi movido para um objeto Description
em ParamValue no J2EE 1.4.
O objeto TagLib no J2EE 1.3 foi movido para o objeto JSPConfig no
J2EE 1.4. Os objetos JSPConfig pertenciam ao objeto raiz da Web
no 1.3.
O Assistente para Migração do J2EE migra os artefatos de um descritor
JCA (J2EE Connector Architecture) 1.0 para o JCA 1.5. Os
artefatos migrados estão relacionados aos elementos do objeto
ResourceAdaptor porque dois novos objetos, OutboundResourceAdaptor e
ConnectionDefinition, foram incluídos no objeto ResourceAdaptor no nível
de especificação J2EE 1.4 para projetos do Connector.
O mapeamento dos elementos migrados está descrito a seguir.
- Os seguintes elementos foram movidos do objeto ResourceAdaptor para o
objeto OutboundResourceAdaptor:
- reauthenticationSupport
- transactionSupport
- Os seguintes elementos foram movidos do objeto ResourceAdaptor para o
objeto ConnectionDefinition:
- managedConnectionFactoryClass
- connectionFactoryInterface
- connectionFactoryImplClass
- connectionInterface
- connectionImplClass
- O objeto outboundResourceAdaptor contém uma lista de definições
ConnectionDefinition. Portanto, ConnectionDefinition é incluído
na lista ConnectionDefinition retida por OutboundResourceAdaptor.
- O objeto OutboundResourceAdaptor está contido no objeto
ResourceAdaptor.
- O objeto AuthenticationMechanism passou por algumas alterações no
JCA 1.5 em que o elemento customAuthMechType é substituído por
authenticationMechanism e o elemento authenticationType é substituído
por authenticationMechanism
- O atributo de descrição no objeto ResourceAdaptor é
substituído por um objeto Description, sendo que a cadeia do atributo
description é definida para elemento de valor no objeto Description para os
seguintes objetos:
- SecurityPermission
- AuthenticationMechanism
- ConfigurationProperties
A especificação J2EE 1.4 incluiu suporte para serviços da
Web através da nova API JAX-RPC 1.0.
A API JAX-RPC suporta nós de extremidade de serviço através
de:
- servlets com JAXR-RPC
- servlets com SOAP direto
- beans de sessão sem preservação de estado
A especificação J2EE 1.4 suporta os serviços da Web para a
especificação J2EE (JSR 109). JSR 109 define os requisitos de
implementação para serviços da Web e utiliza o modelo de
programação JAX-RPC.
Os artefatos de serviços da Web migrados a seguir utilizando o
Assistente para Migração do J2EE são:
- Descritor de serviços da Web
- Descritor de cliente de serviços da Web
- Descritor de mapeamento JAX-RPC
Migrando Descritores de Implementação de Serviço da Web
Qualquer descritor de implementação de serviços da Web contido nos
projetos J2EE 1.3 migrados para o nível de especificação J2EE
1.4 será migrado do JSR-109 V1.0 (para J2EE 1.3) para
J2EE 1.4.
Os descritores de implementação de serviço da Web, conforme
definidos pelo JSR-109 V1.0, consistem nos arquivos
webservices.xml, webservicesclient.xml e todos os descritores de
implementação de mapeamento JAX-RPC que são referidos pelo
webservices.xml e pelo webservicesclient.xml. Como com
outros descritores de implementação J2EE, a migração modificará
a estrutura de informações contida nos descritores para conformidade com
a especificação J2EE 1.4. Uma alteração estrutural
que é específica dos descritores de implementação de serviço da
Web é a alteração na maneira como os nomes completos são
representados. No JSR-109 V1.0, os nomes qualificados são
representados utilizando uma seqüência de dois elementos
<namespaceURI> e <localpart>, que contêm
o URI do espaço de nomes e a parte local do nome respectivamente. Os
nomes completos do J2EE 1.4 são baseados no tipo XMLSchema QName,
que utiliza espaços de nomes XML.
Detalhes adicionais sobre a migração de cada um dos descritores de
implementação do serviço da Web são fornecidos abaixo.
- Descritos de serviços da Web (webservices.xml)
O descritor de implementação webservices.xml está presente
em projetos da Web que contêm serviços J2EE da Web. O elemento
<wsdl-port> e o elemento <soap-header>
contêm nomes qualificados e seus conteúdos serão migrados para o
formato J2EE 1.4.
Por exemplo, se <wsdl-port> for representado da seguinte
maneira antes da migração,
<wsdl-port>
<namespaceURI>http://addressbook.webservice</namespaceURI>
<localpart>AddressBook</localpart>
</wsdl-port>
após a migração <wsdl-port> será representado
como:
<wsdl-port xmlns:pfx="http://addressbook.webservice">pfx:AddressBook</wsdl-port>
O prefixo "pfx" é utilizado como o prefixo do espaço de nomes para
todos os nomes completos migrados.
- Descritor do cliente de serviços da Web
(webservicesclient.xml)
O descritor de implementação webservicesclient.xml está
presente nos projetos da Web do J2EE 1.3 e nos projetos de clientes
aplicativos que contêm clientes de serviços da Web do J2EE.
Durante a migração do J2EE 1.3 para 1.4, o conteúdo do
webservicesclient.xml é migrado e movido para o descritor de
implementação para o projeto. O processo que ocorre é o
seguinte:
- Para projetos da Web, todos os elementos <service-ref> em
webserivcesclient.xml são movidos sob o elemento
<web-app> em web.xml.
- Para projetos do cliente aplicativo, todos os elementos
<service-ref> em webservicesclient.xml são movidos
sob o elemento <application-client> em
application-client.xml.
- Webservicesclient.xml é excluído.
O elemento <service-qname> e o elemento
<soap-header> contêm nomes qualificados e seus
conteúdos serão migrados para o formato J2EE 1.4. Por
exemplo, se <service-qname> for representado da seguinte
maneira antes da migração,
<service-qname>
<namespaceURI>http://addressbook.webservice</namespaceURI>
<localpart>AddressBookService</localpart>
</service-qname>
após a migração <service-qname> será
representado como:
<service-qname xmlns:pfx="http://addressbook.webservice">pfx:AddressBookService</service-qname>
O prefixo "pfx" é utilizado como o prefixo do espaço de nomes para
todos os nomes completos migrados.
- Descritor de mapeamento JAX-RPC
Os descritores de implementação webservices.xml e
webservicesclient.xml podem fazer referência a um ou mais
descritores de implementação de mapeamento JAX-RPC.
No arquivo webservices.xml, essas referências estão contidas
no elemento <jaxrpc-mapping-file> sob cada elemento
<webservice-description>. No arquivo
webservicesclient.xml, essas referências estão contidas no
elemento <jaxrpc-mapping-file> sob cada elemento
<service-ref>.
Durante a migração de J2EE 1.3 para 1.4, todos os
descritores de implementação de mapeamento JAX-RPC referenciados em
webservices.xml e em webservicesclient.xml são
migrados.A migração inclui a migração de todos os nomes
qualificados para o formato J2EE 1.4 (consulte a seção acima em
webservices.xmle em webservicesclient.xml para obter exemplos de
nomes qualificados migrados).
Os módulos J2EE podem ser migrados do nível de especificação
J2EE 1.2 para J2EE 1.4. Essa seção descreve os
artefatos migrados do nível de especificação J2EE 1.2 para
J2EE 1.4 pelo Assistente para Migração do J2EE.
Para obter detalhes sobre como utilizar o Assistente para Migração do
J2EE, consulte Capítulo 3, Migrando Projetos do J2EE.
Artefatos de um descritor de implementação da Web são migrados
pelo Assistente para Migração do J2EE, quando um projeto da Web J2EE
1.2 for migrado para o nível de especificação J2EE
1.4.
Os seguintes artefatos de aplicativos da Web são migrados:
Limitações de Autenticação
O J2EE 1.4 inclui um objeto Description que possui dois
atributos: language e value. Esse objeto
Description não existia no J2EE 1.2; a descrição era um
atributo na Limitação de Autenticação. Portanto, quando os
artefatos de um descritor de implementação da Web são migrados para
J2EE 1.4, o value do objeto Description é obtido do
atributo de descrição da limitação de Autenticação.
Limitações de Segurança
Semelhantemente, no J2EE 1.2 a descrição era um atributo na
Limitação de Segurança. No J2EE 1.4, há um novo
objeto Description com os atributos language e
value. Assim, o value do objeto Description é
obtido do atributo de descrição da Limitação de
Segurança.
Aplicativo da Web
O atributo da cadeia de descrição do objeto ContextParam no nível
de especificação J2EE 1.2 foi movido para um objeto Description
em ParamValue no J2EE 1.4.
O objeto TagLib no J2EE 1.2 foi movido para o objeto JSPConfig no
J2EE 1.4. Os objetos JSPConfig pertenciam ao objeto raiz da Web
no 1.2.
Foram feitas alterações no Assistente para Migração do J2EE no
Rational Web Developer V6.0 comuns à migração de todos os
níveis de especificação J2EE.
Migração da Estrutura do Projeto é Opcional
Do WebSphere Studio V5.1.x até V5.1.2, a
migração da estrutura do projeto ocorre de forma simultânea com a
migração do nível de especificação J2EE. A
migração da estrutura de projeto não foi opcional ao migrar os
níveis de especificação J2EE.
No Assistente para Migração do J2EE no Rational Web Developer
V6.0, Migrar Estrutura do Projeto é uma seleção
opcional separada de Migrar Nível de Especificação J2EE do
Projeto. A migração do nível de especificação J2EE
e a migração da estrutura de projeto podem ser executadas de forma
independente.
Servidor de Destino Requerido
No Rational Web Developer V6.0, projetos do J2EE novos e existentes
migrados para um nível de especificação J2EE mais alto requerem que
um servidor de destino seja definido no projeto. Destino do Servidor
é o mecanismo padrão de como o caminho de classe é definido em um
projeto do J2EE na V6.0. Para obter informações sobre como
definir um servidor de destino utilizando o Assistente para Migração do
J2EE, consulte a ajuda on-line.
No Rational Web Developer V6.0, os ambiente de teste do WebSphere
Application Server fornecidos com o produto foram alterados em relação
àqueles incluídos em edições anteriores do WebSphere Studio Site
Developer.
Segue um resumo das alterações nos ambientes de teste do WebSphere
Application Server no Rational Web Developer V6.0:
- Os servidores WebSphere Application Server V4.x não são mais
suportados nos ambientes de teste. Entretanto, os aplicativos no
nível de especificação J2EE 1.2 ainda podem ser exportados e
implementados manualmente para teste nos servidores remotos
V4.x.
- O servidor WebSphere Application Server V6.0 foi incluído como
um ambiente de teste instalável. Ele suporta a execução de
aplicativos de nível de especificação J2EE 1.4.
A tabela a seguir mostra os níveis do ambiente de teste do WebSphere
Application Server com as diferentes versões do WebSphere Studio Site
Developer e do Rational Web Developer.
Tabela 2. Ambientes de Teste do WebSphere Application Server no WebSphere Studio Site Developer e Rational Web Developer
| WebSphere Application Server V4.x AEs
| WebSphere Application Server V5.x Base
| WebSphere Application Server Express V5.x
| WebSphere Application Server V6.0
|
| WebSphere Studio Site Developer V5.1
| V4.0.6
| V5.0.2
| V5.0.2
| N/A
|
| WebSphere Studio Site Developer V5.1.1
| V4.0.7 + PQ78374
| V5.0.2 + PQ78374 +PQ78419, V5.1
| V5.0.2 & V5.1
| N/A
|
| WebSphere Studio Site Developer V5.1.2
| V4.0.7 + PQ78374
| V5.0.2 + PQ78374 +PQ78419, V5.1.0.3
| V5.0.2 & V5.1.0.3
| N/A
|
| Rational Web Developer V6.0
| N/A
| V5.0.x, V5.1.1
| V5.0.2 e V5.1.1
| V6.0
|
Copyright e Avisos