IBM Rational Application 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 Application Developer V6.0
Capítulo 3. Atualizando Recursos de Tempo de Execução Faces para Projetos de Portlet do Rational Application Developer V6.0
Capítulo 4. Migrando Projetos do J2EE
Capítulo 5. Migrando para o Portal Tools no Rational Application Developer V6.0
Migrando Portlets do WebSphere Portal V4.2 para V5.x
Atualizando Recursos de Tempo de Execução Faces em um Projeto de Portlet
Capítulo 6. Alterações nos Ambientes de Teste do WebSphere
Esta documentação fornece instruções para migrar do WebSphere
Studio Application Developer V5.1.x para o Rational Application
Developer V6.0.
As informações adicionais podem ser localizadas nos seguintes
tópicos:
As informações sobre a utilização do Rational Application
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 Application 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 Application 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 Application 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 Application 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 Application Developer
V6.0. Todos os projetos EGL são migrados com segurança sem
essa perspectiva no Rational Application 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 Application 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
Application 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:
- Se você tiver utilizado o Portal Toolkit
V5.0.2.2 com o WebSphere Studio
V5.1.2 para desenvolver projetos de portlet, seu espaço
de trabalho será migrado automaticamente para ser compatível com o
Rational Application Developer. Consulte Capítulo 5, Migrando para o Portal Tools no Rational Application Developer V6.0 para obter informações adicionais.
- 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 Application 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 Application
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
Application 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 Application 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
Application Developer V5.1.x, será necessário obter os
plug-ins correspondentes para a V6.0 e reinstalá-los.
- Se você tiver instalado ambientes de teste de unidade do WebSphere de
nível anterior ao instalar o Rational Application Developer e se você
utilizar o serviço de sistema de mensagens incorporado, faça upgrade
instalando a versão fornecida com o Rational Application Developer.
Consulte o Guia de Instalação para obter detalhes sobre como
instalar o serviço do sistema de mensagens incorporado.
- Se você utilizar recursos que exijam o Agent Controller, faça seu
upgrade instalando a versão fornecida com o Rational Application
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 Application Developer, ele
é automaticamente migrado. Depois de migrar um espaço de
trabalho, ele não poderá mais ser aberto no WebSphere Studio Application
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 Application 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.
- Executar "Remover Compatibilidade" em um projeto do aplicativo corporativo
(se o aplicativo corporativo ou qualquer um de seus módulos ou projetos de
utilitários precisarem ter compatibilidade com WebSphere Studio Application
Developer V5.1.x).
Um arquivo
.compatibility é criado automaticamente no diretório project
quando um projeto V5.1.x é aberto no espaço de trabalho do
Rational Application Developer V6.0. O arquivo
.compatibility é utilizado pelo Rational Application 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 Application Developer V5.1.x, consulte Desativando a Compatibilidade com o WebSphere Studio V5.1.x.
Considerações do Eclipse
Esta versão do Rational Application 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
Application 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 Application 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 Application
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 Application 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
Application 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
Application Developer V6.0 e o WebSphere Studio Application 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 Application
Developer V6.0, a compatibilidade do projeto do J2EE será perdida e
precisará ser restabelecida.
Compatibilidade do Diagrama UML
Os diagramas UML que existiam no WebSphere Studio Application Developer
V5.1.x são compatíveis com releases posteriores e podem
ser abertos no modo de leitura no Rational Application Developer
V6.0. Na V6.0, o Assistente para Migração do J2EE
migra automaticamente os diagramas UML criados nos projetos do J2EE
V5.1.x durante a migração da estrutura do projeto do
J2EE. Depois de migrados, os diagramas UML podem ser editados no
Rational Application Developer V6.0.
- Nota:
- Os diagramas UML de um espaço de trabalho migrado ou criado no Rational
Application Developer V6.0 não podem ser abertos no WebSphere Studio
Application Developer V5.1.x.
A compatibilidade com o WebSphere Studio Application Developer
V5.1.x pode ser totalmente removida de um projeto do aplicativo
corporativo criado no Rational Application 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 Application 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 Application
Developer V5.1.x.
Os recursos de tempo de execução JavaServer Faces fornecidos,
originalmente, no WebSphere Studio Application Developer V5.1.x
foram atualizado para Rational Application 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 Application 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 Application Developer V5.1.x no Rational Application
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 Application 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 Application 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 Application Developer V5.1.x
foram atualizado para o Rational Application 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 Application 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 Application Developer V5.1.x
Rational Application 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 Application 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 Application 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 Application 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 Application 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 Application 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
Application Developer é aberto no Rational Application 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 Application 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 Application 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
Application 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 Application Developer
V6.0. Se você migrar um espaço de trabalho do WebSphere
Studio Application 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
Application 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 Application 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 Application 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 Application Developer V6.0 foram
atualizados para o Rational Application 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 Application 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 Application
Developer V6.0 para o Rational Application 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 Application 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.
Os recursos de tempo de execução JavaServer Faces e Faces Client
fornecidos originalmente no Rational Application Developer V6.0 foram
atualizados para o Rational Application Developer V6.0.1.
Se você quiser continuar o desenvolvimento em projetos de portlet 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 Application Developer V6.0.1, as
atualizações dos recursos de tempo de execução Faces e Faces
Client ocorrem automaticamente quando um projeto de portlet é importado ou
um espaço de trabalho, que contém recursos de tempo de execução
Faces ou Faces Client desatualizados, é aberto. Depois de importar
um projeto de portlet ou abrir um espaço de trabalho do Rational
Application Developer V6.0 para o Rational Application 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 de portlet:
- Importe um projeto de portlet (ou um espaço de trabalho) com
conteúdo do Faces ou do Faces Client do Rational Application 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 de portlet e selecione Build
(Construir) -> Project (Projeto); o processo de
reconstrução de um projeto abre a janela Project Migration
(Migração de Projetos).
- Se você tiver outros projetos da portlet 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 de portlet 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 portlet ou reiniciar o workbench antes de reconstruir o projeto de
portlet. Se você desativou as construções automáticas,
clique com o botão direito do mouse no projeto de portlet 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.
- Para atualizar os recursos de tempo de execução Faces específicos
do portlet, jsf-portlet.jar e jsf-wp.jar, você precisa seguir
as etapas de atualização manual abaixo.
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 de portlet:
- Crie um novo projeto de portlet chamado JSFP601. 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
JSFP601 e selecione Properties (Propriedades) no
menu.
- Clique em Web Project Features (Recursos do Projeto da Web) e
selecione Add Faces Client Framework for Portlet Project (Incluir
Estrutura do Faces Client no Projeto de Portlet) e, em seguida, clique
em OK.
- Para cada projeto de portlet 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:
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- jsf-portlet.jar
- odc-jsf.jar
- Para qualquer arquivo JAR excluído, copie o arquivo JAR do mesmo nome
no diretório WebContent/WEB-INF/lib do projeto JSFP601 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 o projeto de portlet utilizar a API de portlet da IBM ou o componente
do link de pessoa, copie o arquivo jsf-wp.jar no projeto
original.
- Se você copiar o arquivo odc-jsf.jar, copie também o arquivo
odc-jsf-portlet.jar.
- Exclua o projeto de portlet JSFP601.
O Assistente para Migração do J2EE foi atualizado no Rational
Application 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:
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 Application 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.
O Assistente para Migração do J2EE suporta a migração de
descritores de implementação de bean corporativo do recurso EJB do
nível de especificação J2EE 1.3 para J2EE 1.4.
Os beans de sessão sem preservação de estado e os beans orientados a
mensagens são migrados para o J2EE 1.4.
Migrando Beans de Sessão
O Assistente para Migração do J2EE migra os beans de sessão sem
preservação de estado definidos como SEI (Service Endpoint Interfaces)
no descritor webservices.xml de um projeto EJB no J2EE 1.3 para
o nível de especificação J2EE 1.4, configurando novas service
endpoint interfaces no bean de sessão sem preservação de
estado.
A especificação J2EE 1.4 requer uma SEI definida em um bean de
sessão sem preservação de estado se o bean de sessão não for
utilizado como um nó de extremidade de serviços da Web. Durante a
migração de um EJB JAR, todos os beans de sessão no projeto EJB
recebem o nó de extremidade de serviço definido para o nome utilizado no
descritor webservices.xml do projeto EJB. Segue um exemplo de
como os metadados de um projeto EJB ficarão antes e depois da
migração para o nível de especificação J2EE 1.4.
Projeto EJB em J2EE 1.3: Descritor
webservices.xml com bean de sessão sem preservação
de estado utilizado como uma interface de nó de extremidade de serviço
da Web antes da migração
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE webservices PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web services 1.0//EN"
"http://www.ibm.com/webservices/dtd/j2ee_web_services_1_0.dtd">
<webservices id="WebServices_1084831328093">
<webservice-description id="WebServiceDescription_1084831328093">
<webservice-description-name>EchoEJBService</webservice-description-name>
<wsdl-file>META-INF/wsdl/EchoEJB.wsdl</wsdl-file>
<jaxrpc-mapping-file>META-INF/EchoEJB_mapping.xml</jaxrpc-mapping-file>
<port-component id="PortComponent_1084831328103">
<port-component-name>EchoEJB</port-component-name>
<wsdl-port id="WSDLPort_1084831328103">
<namespaceURI>http://test</namespaceURI>
<localpart>EchoEJB</localpart>
</wsdl-port>
<service-endpoint-interface>test.EchoEJB</service-endpoint-interface>
<service-impl-bean id="ServiceImplBean_1084831328103">
<ejb-link>EchoEJB</ejb-link>
</service-impl-bean>
</port-component>
</webservice-description>
</webservices>
As tags <service-endpoint-interface> e
<service-impl-bean> do exemplo acima definem o bean de
sessão sem preservação de estado "EchoEJB" como um nó de
extremidade de serviço no descritor de serviços da Web no nível de
especificação J2EE 1.3 antes da migração.
Projeto EJB no J2EE 1.4: Descritor de implementação
EJB para o bean de sessão sem preservação de estado "EchoEJB" com
Service Endpoint Interface criado pelo processo de migração
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar>
<ejb-jar id="ejb-jar_ID" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
<display-name>
EchoEJBProject</display-name>
<enterprise-beans>
<session id="EchoEJB">
<ejb-name>EchoEJB</ejb-name>
<home>test.EchoEJBHome</home>
<remote>test.EchoEJB</remote>
<service-endpoint>test.EchoEJB</service-endpoint>
<ejb-class>test.EchoEJBBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
A tag <service-endpoint> no exemplo anterior define
"EchoEJB" como o nó de extremidade de serviço no nível de
especificação J2EE 1.4 após a migração.
Migrando Beans Orientados a Mensagens
O Assistente para Migração do J2EE suporta a migração de beans
orientados a mensagens do EJB 2.0 para o EJB 2.1.
Os beans orientados a mensagens foram introduzidos no EJB 2.0 para
suportar o processamento das mensagens assíncronas de um JMS (Java Message
Service). A especificação do EJB 2.1 expande a
definição do bean orientado a mensagens para que possa suportar qualquer
sistema de mensagens, não apenas JMS.
- Nota:
- Os beans orientados a mensagens, que foram migrados do nível de
especificação EJB 2.0 para EJB 2.1 e são implementados
no WebSphere Application Server versão 6, devem ser implementados em um
adaptador de recursos JCA (Java Connector Architecture) 1.5 em vez de
uma porta listener (como no WebSphere Application Server versão 5).
Você deve utilizar o Editor do Descritor de Implementação para
alterar as configurações de ligação do WebSphere para beans
orientados a mensagens do EJB 2.1 para utilizar o adaptador JCA.
Consulte Configurando um Bean Orientado a Mensagens EJB 2.1 para Utilizar um Adaptador JCA.
Os artefatos do bean orientado a mensagens EJB 2.0 são:
- acknowledgeMode
- messageSelector
- destinationType
- subscriptionDurablity
Alguns dos elementos do bean orientado a mensagens EJB 2.0 são
substituídos pelas propriedades activation-config. Os
nomes de propriedades e os valores utilizados na propriedade
activation-config para descrever o serviço de mensagens variam
dependendo do tipo de serviço de mensagens utilizado. No entanto, o
EJB 2.1 define um conjunto de propriedades fixas para beans orientados
a mensagens com base em JMS.
O exemplo a seguir compara os elementos de um bean de amostra no EJB
2.0 com a aparência que os elementos terão no EJB
2.1.
Um exemplo de elementos do bean orientado a mensagens no EJB
2.0:
<message-driven id="Mdb20">
<ejb-name>Mdb</ejb-name>
<ejb-class>ejbs.MdbBean</ejb-class>
<transaction-type>Bean</transaction-type>
<message-selector>mdbMessage</message-selector>
<acknowledge-mode>Auto-acknowledge</acknowledge-mode>
<message-driven-destination>
<destination-type>javax.jms.Topic</destination-type>
<subscription-durability>Durable</subscription-durability>
</message-driven-destination>
</message-driven>
Um exemplo de elementos do bean orientado a mensagens no EJB
2.1:
<message-driven id="Mdb21">
<ejb-name>Foo/ejb-name>
<ejb-class>ejbs.FooBean</ejb-class>
<messaging-type>javax.jms.MessageListener</messaging-type>
<transaction-type>Bean/transaction-type>
<message-destination-type>javax.jms.Topic</message-destination-type>
<activation-config>
<activation-config-property>
<activation-config-property-name>destinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Topic</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>subscriptionDurability</activation-config-property-name>
<activation-config-property-value>Durable</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>acknowledgeMode</activation-config-property-name>
<activation-config-property-value>AutoAcknowledge</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>messageSelector</activation-config-property-name>
<activation-config-property-value>fooSelector</activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>
Os beans orientados a mensagens, que foram migrados do nível de
especificação Java Bean (EJB) 2.0 para o EJB 2.1 e
implementados no WebSphere Application Server versão 6, devem ser
implementados em um adaptador de recursos JCA (Java Connector Architecture)
1.5 em vez da porta listener.
As seguintes etapas descrevem como alterar o descritor de
implementação do beans orientado a mensagens do EJB 2.1 para
utilizar um adaptador JCA:
- Abra o projeto EJB no Explorer do Projeto.
- Dê um clique duplo no arquivo Deployment Descriptor (Descritor de
Implementação) do projeto EJB no Explorer do Projeto. O
editor do descritor de implementação EJB é aberto.
- Clique na guia Bean para abrir a página
Bean.
- Para cada bean orientado a mensagens do EJB 2.1 no projeto EJB,
faça o seguinte:
- Selecione o bean orientado a mensagens do EJB 2.1 na lista de beans
no lado esquerdo da página Bean.
- Abaixo do título WebSphere Bindings (Ligações do
WebSphere), selecione o botão JCA Adapter (Adaptador
JCA).
- Especifique as propriedades de implementação das
ligações:
- Nome JNDI de ActivationSpec.
Digite o nome JNDI da especificação de ativação do J2C que deve
ser utilizado para implementar esse bean orientado a mensagens. Esse
nome deve corresponder ao nome de uma especificação de ativação do
J2C definido para o WebSphere Application Server.
- Alias de Autorização ActivationSpec.
O nome de um alias de autenticação do J2C utilizado para a
autenticação de conexões para o adaptador de recursos JCA. Um
alias de autenticação do J2C especifica o Id do usuário e a senha
utilizados para autenticar a criação de uma nova conexão para o
adaptador de recursos JCA.
- Nome JNDI de Destino.
Digite o nome JNDI que o bean orientado a mensagens utiliza para consultar
o destino de JMS no espaço de nomes JNDI.
- Salve as alterações e feche o editor Descritor de
Implementação.
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 e projetos EJB 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, nos projetos EJB 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.
- Para projetos EJB, todos os elementos <service-ref>
dentro de um <component-scoped-refs> no
webserviceclient.xml são movidos sob o
<enterprise-bean> correspondente em
ejb-jar.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 4, Migrando Projetos do J2EE.
A migração de um projeto EJB do nível de especificação EJB
1.1 para EJB 2.1 é descrita nesta seção.
A migração de um projeto EJB do EJB 1.1 para EJB 2.1
envolve a migração de beans de entidade CMP (Container-Managed
Persistence).
Não houve alterações nos beans de entidade entre o nível de
especificação J2EE 1.3 e J2EE 1.4. A migração
de beans de entidade CMP do nível de especificação EJB 1.1
para EJB 2.1 é feita da mesma maneira que a migração de um
bean de entidade CMP de EJB 1.1 para EJB 2.0. A
migração de beans de entidade gerenciados por contêiner do nível
de especificação EJB 1.1 para EJB 2.x requer as seguintes
etapas:
- Conversão do projeto EJB do EJB 1.1
para EJB 2.x.
- Migração do código EJB do EJB 1.1
para EJB 2.x.
- Migração de quaisquer referências
EJB 1.1 definidas pelo usuário para referências locais no EJB
2.x.
Um projeto EJB 1.1 pode ser convertido em um projeto EJB 2.x,
utilizando o Assistente para Migração do J2EE.
- Na exibição J2EE Hierarchy, clique com o botão direito no projeto
1.1 e selecione Migrate (Migrar) -> J2EE
Migration Wizard (Assistente de Migração do J2EE).
Ou, se você quiser preservar o projeto EJB 1.1 original,
poderá criar um novo projeto 2.x e, em seguida, importar o arquivo
JAR do projeto existente para ele (File (Arquivo) ->
Import (Importar) -> EJB JAR).
Apesar do projeto se um projeto EJB 2.x, os beans de entidade CMP
(Container-managed Persistence) EJB 1.1 existentes (ou importados)
permanecem como beans EJB 1.1. Ou seja, os beans de entidade CMP
não são convertidos para EJB 2.x.
O Assistente para Migração do J2EE migra os beans corporativos de um
projeto EJB 2.x de 1.1 para 2.x. (Se você optar
por migrar seus beans de entidade CMP 1.1 para 2.x, todos os
beans do projeto 2.x devem ser migrados. No entanto, você
pode optar seletivamente por incluir visualizações do cliente local
nesses beans 2.x migrados.)
- O assistente manterá a herança do EJB 1.1 existente no
projeto EJB 2.x.
- Ele migrará os relacionamentos do EJB 1.1 (proprietário) para
os relacionamentos do EJB 2.x (padrão), além de outros
benefícios.
- Nota:
- Se você tiver quaisquer associações mapeadas, as associações
do EJB 2.x serão criadas para as próprias associações, mas
os mapas de funções para essas associações se tornarão
inválidos. Se você executar a validação, ocorrerá um
erro. Para impedir que isso aconteça, abra o editor de mapeamento
primeiro e salve o mapa. Os mapas de função serão
removidos. Depois, você poderá executar novamente a
validação e remapear as funções.
Para projetos convertidos do EJB 1.1 para EJB 2.x, devem ser
executadas etapas para migrar os projetos EJB 1.1 existentes para o EJB
2.x.
- Nota:
- Os beans do EJB 2.x são suportados somente em um projeto EJB
2.x (apesar do projeto 2.x também suportar os beans
1.1).
- Para qualquer bean CMP 1.1, substitua cada campo CMP por métodos
abstratos getXXX e setXXX. (Então, é
necessário que a classe de beans seja abstrata.)
- Para qualquer CMP, crie um método getXXX e setXXX
abstrato para a chave primária.
- Para qualquer método localizador CMP 1.1, crie um método
EJBQL (EJB Query Language) para cada método localizador.
- Nota:
- EJB Query Language tem as seguintes limitações no Rational Application
Developer V6.0:
- As consultas do EJB Query Language envolvendo EJBs com chaves compostas de
relações com outros EJBs aparecerão como inválidas e provocarão
erros no tempo de implementação.
- O suporte ao IBM EJB Query Language estende a especificação do EJB
2.x de diversas maneiras, diminuindo algumas restrições,
incluindo suporte para mais funções do DB2 e assim por diante. Se
a portabilidade através de diversos bancos de dados de fornecedores ou
ferramenta de implementação de EJB for uma preocupação, deve-se
tomar cuidado para gravar todas as consultas do EJB Query Language
estritamente de acordo com as instruções descritas no Capítulo 11 da
especificação do EJB 2.x.
- Para qualquer localizador CMP 1.1, retorne
java.util.Collection em vez de
java.util.Enumeration.
- Para qualquer bean CMP 1.1, altere todas as ocorrências de
this.field = value para setField(value) em
ejbCreate() e no código todo.
- Atualize seu tratamento de exceção (comportamento de reversão)
para exceções não de aplicativos:
- Ative javax.ejb.EJBException ao invés de
java.rmi.RemoteException para comunicar
exceções que não sejam do aplicativo.
- No EJB 2.x e 1.1, todas as exceções não de
aplicativos lançadas pela instância resultam na reversão da
transação na qual a instância foi executada e no descarte da
instância.
- Atualize seu tratamento de Exceção (comportamento de reversão)
para exceções de aplicativos:
- No EJB 2.x e 1.1, uma exceção de aplicativo não faz
com que o contêiner reverta uma transação automaticamente.
- No EJB 1.1, o contêiner executa a reversão apenas se a
instância tiver sido chamada com o método setRollbackOnly()
em seu objeto EJBContext.
- Atualize todos os valores padrão específicos da definição de
aplicativo do CMP para que estejam em ejbCreate (não utilizando
variáveis globais, pois os contêineres do EJB 1.1 definiram todos
os campos como valores padrão genéricos antes de chamar
ejbCreate, que sobrescreverá todos os padrões específicos
do aplicativo anterior).
Durante a criação de relações do EJB 1.1, foram criadas
referências EJB para a visualização Remote Client. Durante a
migração de projetos EJB 1.1 utilizando o Assistente para
Migração do J2EE, essas referências remotas ao EJB para as
relações do EJB 1.1 são removidas e substituídas por
referências locais ao EJB. As referências locais às
referências ao EJB definidas pelo usuário devem ser recriadas
manualmente.
- Nota:
- No EJB 2.x, as relações do EJB podem ser criadas somente se os
beans tiverem a visualização Cliente Local definida neles e as
referências locais ao EJB forem criadas para as relações do EJB
2.x.
Para referências ao EJB definidas pelo usuário, não
é feita nenhuma migração utilizando o Assistente para Migração
do J2EE. Entretanto, siga estas etapas para configurar as
referências locais:
- Exclua as referências remotas ao EJB existentes na página
Referências do editor do descritor de implementação.
- Inclua uma referência local ao EJB na página Referências do
editor do descritor de implementação.
Durante a migração da estrutura do projeto utilizando o Assistente
para Migração do J2EE, os elementos do método (que incluem identidade
de segurança, transação do contêiner, permissão do método,
intenção de acesso e níveis de isolamento) do mesmo tipo para todos
os beans são mesclados para serem agrupados de forma lógica.
Uma amostra dos elementos do método antes e depois da migração da
estrutura do projeto.
Segue uma amostra da permissão do método na página Source do
editor do descritor de implementação antes da migração da
estrutura do projeto.
<method-permission>
<role-name>rol1</role-name>
<role-name>rol2</role-name>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getEJBMetaData</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getHomeHandle</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-namae>remove</method-name>
<method-params>
<method-param>java.lang.Object</method-param>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>javax.ejb.Handle</method-param>
</method-params>
</method>
</method-permission>
<method-permission>
<role-name>rol1</role-name>
<role-name>rol2</role-name>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Remote</method-intf>
<method-name>isIdentical</method-name>
<method-params>
<method-param>javax.ejb.EJBObject</method-param>
</method-params>
</method>
</method-permission>
Segue uma amostra da permissão do método na página Source do
editor do descritor de implementação depois da migração da
estrutura do projeto.
<method-permission>
<role-name>rol1</role-name>
<role-name>rol2</role-name>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getEJBMetaData</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getHomeHandle</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>>java.lang.Object</method-param>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>javax.ejb.Handle</method-param>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Remote</method-intf>
<method-name>isIdentical</method-name>
<method-params>
<method-param>javax.ejb.EJBObject</method-param>
</method-params>
</method>
</method-permission>
- Nota:
- Quando a migração de beans do CMP 1.x para o CMP 2.x
também é selecionada juntamente com a migração da estrutura do
projeto no Assistente para Migração do J2EE, a intenção de acesso
e os níveis de isolamento são removidos, mas o restante é mesclado
durante a migração. A razão pela qual as intenções de
acesso e o nível de isolamento são removidos é que eles não são
mais válidos devido às alterações no modelo de
extensões. Com o novo modelo, as intenções de acesso e o
nível de isolamento são definidos em intenções de acesso e existem
a intenção de acesso do nível de beans e a intenção de acesso
do nível de métodos. Sempre é recomendado utilizar a
intenção de acesso do nível de beans em vez da intenção de
acesso do nível de métodos.
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 Application 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 Application 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 Application 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.
Os projetos do Portal Toolkit V5.0.2.2 serão
migrados automaticamente para o Rational Application Developer V6.0
Portal Tools, migrando o espaço de trabalho do Portal Toolkit ou carregando
o projeto de um sistema SCM (Source Code Management) ou importando o projeto
utilizando o recurso Intercâmbio de Projetos. Se estiver migrando de
versões anteriores do Portal Toolkit, você precisará exportar seus
projetos de portlet para arquivos WAR e importar os arquivos WAR para o Portal
Tools no Rational Application Developer V6.0.
Antes de migrar aplicativos do portal, será necessário instalar o
recurso Portal Tools do Rational Application Developer V6.0.
Consulte o Guia de Instalação.
- Nota:
- Compatibilidade com releases anteriores de projetos de portlets não é
suportada.
A migração automática é suportada apenas para projetos criados
no Portal Toolkit V5.0.2.2 com o WebSphere Studio
V5.1.2. Consulte Capítulo 1, Migrando do WebSphere Studio V5.1, 5.1.1 ou 5.1.2 para obter detalhes sobre a migração.
Se seu projeto de portlet estiver associado a um projeto do aplicativo
corporativo, você precisará definir o servidor de destino apropriado no
projeto EAR. Você pode definir o servidor de destino na página
Propriedades do Servidor (Propriedades ->
Servidor).
Durante a migração de projetos do Portal Toolkit
V5.0.2.2, ocorrem algumas alterações
adicionais:
- O servidor de destino é definido para WebSphere Portal V5.0, se
nenhum servidor de destino estiver definido para o projeto.
- O caminho de construção do portlet é corrigido
- Nature de um projeto de portlet é incluída.
Se estiver migrando de versões anteriores do Portal Toolkit, você
precisará migrar manualmente seus projetos de portlet para o Portal Tools
no Rational Application Developer V6.0, da seguinte maneira:
- Exporte o projeto existente para um arquivo WAR: Na versão
anterior do Portal Toolkit, exporte cada projeto para um arquivo WAR com
arquivos de origem.
- Clique com o botão direito do mouse no projeto e selecione
Exportar.
- Selecione o arquivo WAR e Exportar Arquivos de
Origem e clique em Concluir.
- Importe o arquivo WAR do portlet:
- No Portal Tools do Rational Application Developer V6.0, crie um
novo projeto de portlet vazio.
- Selecione Arquivo -> Novo ->
Projeto -> Portal -> Projeto de Portlet
ou Projeto de Portlet (JSR 168).
- Cancele a seleção de Criar um Portlet.
- Clique em Mostrar Avançado.
- Se você estiver importando um portlet do WebSphere Portal 4.2,
selecione 2.2 como a versão do servlet.
- Selecione WebSphere Portal v5.0 como o servidor de
destino e clique em Concluir.
- Importe o arquivo WAR para esse novo projeto de portlet vazio.
- Selecione Importar.
- Selecione Arquivo WAR e especifique o arquivo WAR exportado
acima (Exportando Projeto para Arquivo WAR na Versão Anterior).
- Selecione o novo projeto de portlet vazio.
- Selecione Sobrescrever Recursos Existentes Sem Aviso.
- Não selecione Excluir Projeto na
Sobreposição.
- Exclua o arquivo TLD:
Recomenda-se excluir o arquivo TLD do portlet a partir do projeto se ele
existir. Do contrário, você receberá uma mensagem de aviso ao
reconstruir o projeto. Deixá-lo pode causar um problema quando o
projeto de portlet for implementado para o WebSphere Portal e o arquivo TLD do
portlet for diferente do arquivo no servidor.
- Se você estiver migrando um portlet do WebSphere Portal 4.2,
precisará migrar esse projeto do portlet migrado para o WebSphere Portal
5.x.
Para obter informações sobre como migrar os portlets do WebSphere
Portal V4.2 para V5.x, consulte Migrando Portlets do WebSphere Portal V4.2 para V5.x.
Para obter informações sobre como migrar recursos Faces em um projeto
de portlet, consulte Atualizando Recursos de Tempo de Execução Faces em um Projeto de Portlet.
O Rational Application Developer V6.0 não suporta o
desenvolvimento de portlets do WebSphere Portal V4.2. Você
precisa migrar os projetos de portlet do WebSphere Portal V4.2 para
V5.x.
A maioria dos portlets gravados para o WebSphere Portal V4.2
serão executados inalterados no WebSphere Portal V5.x.
Algumas das APIs do Portlet 4.2.x estão agora marcadas como
obsoletas, mas ainda estão disponíveis no WebSphere Portal
V5.x.
- Nota:
- Os projetos de aplicativos de portlets migrados não são compatíveis
com releases anteriores.
Para migrar aplicativos de portlets do WebSphere Portal V4.2 para
V5.x, execute as seguintes etapas:
- Migre os projetos de portlets do Portal V4.2 para os projetos de
portlets do Portal V5.x:
- Clique com botão direito do mouse no projeto de aplicativo do portlet
que deseja migrar.
- Selecione Propriedades -> API do Portlet para
abrir a página API do Portlet.
- Selecione WebSphere Portal Versão 5.x na lista
drop-down Nível de API do Portlet.
- Clique em OK e as alterações a seguir são feitas
automaticamente:
- O arquivo TLD (Tag Library Descriptor) da API do portlet será removido,
se existir.
- O nível da Web é alterado de 2.2 para 2.3.
- As entradas do caminho de classe específico do portlet são
removidas, uma vez que o contêiner JRE do WebSphere Portal e o contêiner
de destino do tempo de execução do WebSphere Portal as incluirão
dinamicamente.
- Se seu projeto de portlet for associado a um projeto do aplicativo
corporativo, recomenda-se migrar o nível de J2EE do projeto EAR para J2EE
1.3. Aplicativos de portlet projetados para o WebSphere Portal
V5.x devem ser compatíveis com as especificações de nível
J2EE 1.3.
- Nota:
- Antes de migrar seu projeto do aplicativo corporativo para J2EE 1.3,
leia Capítulo 4, Migrando Projetos do J2EE. Para obter informações sobre como utilizar o
Assistente para Migração do J2EE, consulte a ajuda on-line.
- Se o projeto de portlet migrado estiver associado somente ao projeto do
aplicativo corporativo, proceda da seguinte forma:
- Feche todos os editores do workbench.
- Clique com o botão direito do mouse no projeto do aplicativo
corporativo ao qual o projeto de portlet migrado está associado.
- Selecione Migrar -> Assistente para Migração
do J2EE e clique em Avançar.
- Selecione J2EE Versão 1.3 e WebSphere
Portal como o servidor de destino.
- Clique em Concluir.
- Se outros projetos de portlet estiverem associados ao projeto do
aplicativo corporativo, você deverá remover o projeto de portlet migrado
e incluí-lo em outro projeto do aplicativo corporativo.
- Remova o módulo do projeto do portlet migrado do projeto do aplicativo
corporativo.
- Expanda o projeto do aplicativo corporativo e selecione o descritor de
implementação.
- Selecione Open With -> Deployment Descriptor
Editor.
- Selecione a guia Módulo. Na página Módulo do
editor, selecione o arquivo WAR do projeto do portlet migrado.
- Clique em Remover.
- Selecione Arquivo -> Salvar para salvar as
alterações.
- Crie um novo projeto do aplicativo corporativo e inclua o projeto de
portlet nele.
- Selecione Arquivo -> Novo ->
Projeto.
- Selecione a caixa de opções Mostrar Todos os
Assistentes.
- Expanda o J2EE e selecione Projeto do Aplicativo
Corporativo.
- Preencha o campo Nome do projeto, selecione J2EE Versão
1.3 e WebSphere Portal como o servidor de destino e
clique em Avançar.
- Na página Projetos do Módulo EAR, selecione o projeto de
portlet migrado e clique em Concluir.
O projeto do portlet é agora migrado para o WebSphere Portal
V5.x.
Os recursos de tempo de execução JavaServer Faces fornecidos
originalmente no WebSphere Studio Application Developer V5.1.2
foram atualizados para o Rational Application Developer
V6.0.1. Se você quiser continuar o desenvolvimento em
projetos de portlet criados com o Portal Toolkit 5.0.2.2
para 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 Application Developer V6.0.1, as
atualizações dos recursos de tempo de execução Faces ocorrem
automaticamente quando um projeto de portlet é importado ou um espaço de
trabalho, que contém recursos desatualizados, é aberto. Depois de
importar um projeto de portlet criado com o Portal Toolkit
5.0.2.2 para WebSphere Studio Application Developer
V5.1.x para o Rational Application 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 de portlet:
- Importe um projeto de portlet com conteúdo do Faces do WebSphere Studio
Application 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 de portlet e selecione Build
(Construir) -> Project (Projeto); o processo de
reconstrução de um projeto abre a janela Project Migration
(Migração de Projetos).
- Se você tiver outros projetos de portlet 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 de portlet
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 portlet ou reiniciar o workbench antes de reconstruir o projeto de
portlet. Se você desativou as construções automáticas,
clique com o botão direito do mouse no projeto de portlet 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.
- Para atualizar os recursos de tempo de execução Faces específicos
do portlet, jsf-portlet.jar e jsf-wp.jar, você precisa seguir
as etapas de atualização manual abaixo.
- 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 de portlet:
- Importe um projeto de portlet existente com conteúdo do Faces para um
espaço de trabalho Rational Application Developer
V6.0.1.
- Crie um novo projeto de portlet denominado JSFP601 com a
opção Faces portlet (Portlet Faces) selecionada na segunda
página. 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
JSFP601 e selecione Properties (Propriedades) no
menu.
- Clique em Web Project Features (Recursos do Projeto da Web) e
selecione Add Faces Client Framework for Portlet Project (Incluir
Estrutura do Faces Client no Projeto de Portlet) e, em seguida, clique
em OK.
- 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:
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- jsf-portlet.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>
<variable-resolver>com.ibm.faces.application.WPPortletVariableResolver</variable-resolver>
<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
</application>
- Nota:
- Se o projeto do portlet estiver utilizando a API JSR 168, especifique
com.ibm.faces.application.PortletVariableResolver
em vez de
com.ibm.faces.application.WPPortletVariableResolver.
- Para qualquer arquivo JAR excluído, copie o arquivo JAR do mesmo nome
no diretório WebContent/WEB-INF/lib do projeto JSFP601 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 o projeto de portlet utilizar a API de portlet da IBM ou o componente
do link de pessoa, copie o arquivo jsf-wp.jar no projeto
original.
- Se você copiar o arquivo odc-jsf.jar, copie também o arquivo
odc-jsf-portlet.jar.
- 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>
- Exclua o projeto de portlet JSFP601.
No Rational Application 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 Application Developer.
Segue um resumo das alterações nos ambientes de teste do WebSphere
Application Server no Rational Application 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.
- O ambiente de teste do WebSphere Portal foi incluído para testar
portais e aplicativos portlet.
A tabela a seguir mostra os níveis do ambiente de teste do WebSphere
Application Server com as diferentes versões do WebSphere Studio
Application Developer e do Rational Application Developer.
Tabela 2. Ambientes de Teste do WebSphere Application Server no WebSphere Studio Application Developer e Rational Application Developer
| WebSphere Application Server V4.x AEs
| WebSphere Application Server V5.x Base
| WebSphere Application Server Express 5.x
| WebSphere Application Server V5.x Portal
| WebSphere Application Server V6.0
|
WebSphere Studio Application Developer V5.1
| V4.0.6
| V5.0.2
| V5.0.2
| N/A
| N/A
|
WebSphere Studio Application Developer V5.1.1
| V4.0.7 + PQ78374
| V5.0.2 + PQ78374 +PQ78419, V5.1
| V5.0.2 & V5.1
| N/A
| N/A
|
WebSphere Studio Application Developer V5.1.2
| V4.0.7 + PQ78374
| V5.0.2 + PQ78374 +PQ78419, V5.1.0.3
| V5.0.2 & V5.1.0.3
| V5.0.2.3 Base + WebSphere Portal
V5.0.2.1
| N/A
|
Rational Application Developer V6.0
| N/A
| V5.0.x, V5.1.1
| V5.0.2 e V5.1.1
| V5.0.2.6 Base + WebSphere Portal
V5.0.2.2, V5.1.1 Base + WebSphere Portal
5.1
| V6.0
|
Copyright e Avisos