IBM Rational Application Developer para Windows e Linux, Versão 6.0 : Guia de Migração


Índice

Capítulo 1. Migrando do WebSphere Studio V5.1, 5.1.1 ou 5.1.2

  • Compatibilidade com o WebSphere Studio V5.1.x
  • Desativando a Compatibilidade com o WebSphere Studio V5.1.x
  • Atualizando Recursos de Tempo de Execução Faces em um Projeto da Web
  • Atualizando Recursos de Tempo de Execução Faces Client em um Projeto da Web
  • Migrando Projetos da Web Struts
  • Alterações do Depurador na V6.0
  • Migração do WDO para o SDO
  • Palavras Reservadas do EGL na V6.0
  • 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

  • Migrando Serviços da Web Protegidos
  • Migração do Nível de Especificação J2EE 1.3 para 1.4
  • Projetos do Enterprise JavaBean (EJB 2.0 para EJB 2.1)
  • Projetos da Web (Nível de Servlet 2.3 para Nível de Servlet 2.4)
  • Projetos do Conector (JCA 1.0 para JCA 1.5)
  • Serviços da Web (J2EE 1.3 para J2EE 1.4)
  • Migração do Nível de Especificação J2EE 1.2 para 1.4
  • Migrando Projetos Enterprise JavaBeans (EJB 1.1 para EJB 2.1)
  • Projetos da Web (Nível de Servlet 2.2 para Nível de Servlet 2.4)
  • Alterações no Assistente para Migração do J2EE no Rational Application Developer V6.0
  • 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



    Capítulo 1. Migrando do WebSphere Studio V5.1, 5.1.1 ou 5.1.2

    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:

    1. 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.
    2. Faça backup do espaço de trabalho do WebSphere Studio V5.1.x.
    3. 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.
    4. 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).
    5. 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:
      1. 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:

        1. Feche a perspectiva, selecionando Janela -> Fechar Perspectiva
        2. 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:
        1. Feche a perspectiva da Web do EGL.
        2. 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.
        3. Selecione Janela -> Abrir Perspectiva e escolha a perspectiva da Web.
      2. 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.
      3. 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:

      Importante:

    6. 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.
    7. 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.
    8. 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.
    9. 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.
    10. 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.
    11. 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.

    Compatibilidade com o WebSphere Studio V5.1.x

    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:

    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 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:

    1. Abra o arquivo .classpath para cada projeto do J2EE que tem um arquivo .classpath.
    2. Exclua as seguintes entradas do caminho de classe do arquivo .classpath, salve e feche o arquivo.
    3. 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".
    4. Clique com o botão direito do mouse e selecione Propriedades -> J2EE.
    5. 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.
    6. 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.

    Desativando a Compatibilidade com o WebSphere Studio 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:

    1. Clique com o botão direito em um projeto do aplicativo corporativo e selecione a opção de menu Remover Compatibilidade no pop-up.
    2. 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.
    3. 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.


    Atualizando Recursos de Tempo de Execução Faces em um Projeto da Web

    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:

    1. 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).
    2. 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.
    3. Clique em um dos seguintes:
    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:

    1. 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.
    2. 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.
    3. No Explorer do Projeto, clique com o botão direito do mouse no projeto JSF601 e selecione Properties (Propriedades) no menu.
    4. 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.
    5. Se você estiver trabalhando com EGL, crie um arquivo de páginas JSF da seguinte forma:
      1. Clique com o botão direito do mouse na pasta WebContent de seu novo projeto da Web EGL.
      2. Selecione Novo -> Outro -> Arquivo Faces JSP.
      Os arquivos eglintdebug.jar e eglintdebugsupport.jar são incluídos no projeto.
    6. Para cada projeto Faces existente que deseja atualizar, faça o seguinte:
      1. 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
      2. 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>
        
      3. 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.
      4. 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>
        
      5. Se o projeto original utilizou o WDO (WebSphere Data Objects) para qualquer acesso aos dados, execute as seguintes etapas adicionais:
        1. 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.
        2. Arraste um componente da lista de registros relacionais da gaveta Dados na paleta para a página.
        3. 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.
        4. Exclua o arquivo JSP temporário.
      6. 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.
    7. Exclua o projeto da Web JSF601.

    Atualizando Recursos de Tempo de Execução Faces Client em um Projeto da Web

    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:

    1. 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).
    2. 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.
    3. Clique em um dos seguintes:
    4. 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.
    5. 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.
    6. Para cada objeto de dados na visualização Dados do Cliente:
      1. Clique com o botão direito do mouse e selecione Configure (Configurar).
      2. 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:

    1. 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.
    2. 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:

    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:

    1. Gere os novos processadores e rotinas de tratamento Diff em cada objeto de dados do cliente no projeto da Web.
      1. Selecione o objeto de dados do cliente, clique com o botão direito do mouse e selecione Configure (Configurar).
      2. Na guia Advanced (Avançado), clique em Regenerate All (Gerar Tudo Novamente).
    2. 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";
      
    3. 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.

    Alterações nos componentes Faces Client no V6.0


    Migrando Projetos da Web Struts

    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:

    1. Abra o projeto da Web Struts no Explorer do Projeto.
    2. 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.
    3. Clique na guia Source (Origem) para abrir a página Source (Origem).
    4. 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> .

    5. 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:

    1. Carregue os projetos Struts 1.1 Beta em um espaço de trabalho do Rational Application Developer V6.0.
    2. 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.
    3. Para cada projeto Struts 1.1 Beta que deseja converter para Struts 1.1, faça o seguinte:
      1. Exclua os seguintes arquivos JAR do diretório Content/WEB-INF/lib da Web do projeto:
        • commons-*.jar.
        • struts.jar.
      2. 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.
      3. Exclua os seguintes arquivos do TLD (Tag Library Descriptor) do diretório Content/WEB-INF da Web do projeto: struts-*.tld.
      4. 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:

    1. Carregue os projetos Struts 1.0.2 em um espaço de trabalho Rational Application Developer V6.0.
    2. 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.
    3. Para cada projeto Struts 1.0.2 que deseja converter para Struts 1.1, faça o seguinte:
      1. Exclua o arquivo struts.jar do diretório Content/WEB-INF/lib da Web do projeto.
      2. 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.
      3. Exclua os seguintes arquivos do TLD (Tag Library Descriptor) do diretório Content/WEB-INF da Web do projeto: struts-*.tld.
      4. 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.

    Alterações do Depurador na V6.0

    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 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:


    Migração do WDO para o SDO

    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:

    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

    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:

    1. 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;
      
    2. 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:

    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:

    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

    Palavras Reservadas do EGL na V6.0

    Há novas palavras reservadas do EGL (Enterprise Generation Language) no Rational Application Developer.

    As novas palavras reservadas estão listadas aqui:

    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.


    Capítulo 2. Atualizando Recursos de Tempo de Execução Faces para Projetos da Web do Rational Application Developer V6.0

    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:

    1. 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).
    2. 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.
    3. Clique em um dos seguintes:

    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:

    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.
    2. No Explorer do Projeto, clique com o botão direito do mouse no projeto JSF601 e selecione Properties (Propriedades) no menu.
    3. 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.
    4. Se você estiver trabalhando com EGL, crie um arquivo de páginas JSF da seguinte forma:
      1. Clique com o botão direito do mouse na pasta WebContent de seu novo projeto da Web EGL.
      2. Selecione Novo -> Outro -> Arquivo Faces JSP.
      Os arquivos eglintdebug.jar e eglintdebugsupport.jar são incluídos no projeto.
    5. Para cada projeto Faces existente que deseja atualizar, faça o seguinte:
      1. 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
      2. 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.
      3. 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.
    6. Exclua o projeto da Web JSF601.

    Capítulo 3. Atualizando Recursos de Tempo de Execução Faces para Projetos de Portlet do Rational Application Developer V6.0

    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:

    1. 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).
    2. 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.
    3. Clique em um dos seguintes:
    4. 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:

    1. 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.
    2. No Explorer do Projeto, clique com o botão direito do mouse no projeto JSFP601 e selecione Properties (Propriedades) no menu.
    3. 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.
    4. Para cada projeto de portlet Faces existente que deseja atualizar, faça o seguinte:
      1. 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
      2. 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.
    5. Exclua o projeto de portlet JSFP601.

    Capítulo 4. Migrando Projetos do J2EE

    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:

    O Assistente para Migração do J2EE pode ser acessado da seguinte forma:

    1. Na visualização Hierarquia J2EE da perspectiva J2EE, clique com o botão direito do mouse no projeto do aplicativo corporativo que deseja migrar.
    2. Selecione Migrar -> Assistente para Migração do J2EE a partir do menu pop-up.
    3. 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.


    Migrando Serviços da Web Protegidos

    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:

    1. Dê um clique duplo no arquivo webservices.xml para abrir o editor de Serviços da Web.
    2. Selecione a guia Configurações de Ligações para editar o arquivo de ligação.
    3. 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.
    4. Selecione a guia Extensão para editar o arquivo de extensões.
    5. 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.
    6. Salve e saia do editor.

    Migração do Nível de Especificação J2EE 1.3 para 1.4

    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.

    Projetos do Enterprise JavaBean (EJB 2.0 para EJB 2.1)

    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:

    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>
    

    Configurando um Bean Orientado a Mensagens EJB 2.1 para Utilizar um Adaptador JCA

    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:

    1. Abra o projeto EJB no Explorer do Projeto.
    2. 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.
    3. Clique na guia Bean para abrir a página Bean.
    4. Para cada bean orientado a mensagens do EJB 2.1 no projeto EJB, faça o seguinte:
      1. Selecione o bean orientado a mensagens do EJB 2.1 na lista de beans no lado esquerdo da página Bean.
      2. Abaixo do título WebSphere Bindings (Ligações do WebSphere), selecione o botão JCA Adapter (Adaptador JCA).
      3. Especifique as propriedades de implementação das ligações:
        1. 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.

        2. 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.

        3. 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.

    5. Salve as alterações e feche o editor Descritor de Implementação.

    Projetos da Web (Nível de Servlet 2.3 para Nível de Servlet 2.4)

    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.

    Projetos do Conector (JCA 1.0 para JCA 1.5)

    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.

    Serviços da Web (J2EE 1.3 para J2EE 1.4)

    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:

    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:

    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.


    Migração do Nível de Especificação J2EE 1.2 para 1.4

    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.

    Migrando Projetos Enterprise JavaBeans (EJB 1.1 para EJB 2.1)

    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:

    1. Conversão do projeto EJB do EJB 1.1 para EJB 2.x.
    2. Migração do código EJB do EJB 1.1 para EJB 2.x.
    3. Migração de quaisquer referências EJB 1.1 definidas pelo usuário para referências locais no EJB 2.x.

    Convertendo Projetos do EJB 1.2 para 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.

    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.)

    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.

    Migrando Código do EJB 1.1 para o EJB 2.x

    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).

    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.)
    2. Para qualquer CMP, crie um método getXXX e setXXX abstrato para a chave primária.
    3. 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.
    4. Para qualquer localizador CMP 1.1, retorne java.util.Collection em vez de java.util.Enumeration.
    5. 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.
    6. Atualize seu tratamento de exceção (comportamento de reversão) para exceções não de aplicativos:
    7. Atualize seu tratamento de Exceção (comportamento de reversão) para exceções de aplicativos:
    8. 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).

    Migrando Referências EJB para Relações do EJB 1.1

    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:

    1. Exclua as referências remotas ao EJB existentes na página Referências do editor do descritor de implementação.
    2. Inclua uma referência local ao EJB na página Referências do editor do descritor de implementação.

    Os elementos de métodos são mesclados durante a migração da estrutura do projeto

    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.

    Projetos da Web (Nível de Servlet 2.2 para Nível de Servlet 2.4)

    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.


    Alterações no Assistente para Migração do J2EE no Rational Application Developer V6.0

    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.


    Capítulo 5. Migrando para o Portal Tools no Rational Application Developer V6.0

    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:

    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:

    1. 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.
      1. Clique com o botão direito do mouse no projeto e selecione Exportar.
      2. Selecione o arquivo WAR e Exportar Arquivos de Origem e clique em Concluir.
    2. Importe o arquivo WAR do portlet:
      1. No Portal Tools do Rational Application Developer V6.0, crie um novo projeto de portlet vazio.
        1. Selecione Arquivo -> Novo -> Projeto -> Portal -> Projeto de Portlet ou Projeto de Portlet (JSR 168).
        2. Cancele a seleção de Criar um Portlet.
        3. Clique em Mostrar Avançado.
        4. Se você estiver importando um portlet do WebSphere Portal 4.2, selecione 2.2 como a versão do servlet.
        5. Selecione WebSphere Portal v5.0 como o servidor de destino e clique em Concluir.
      2. Importe o arquivo WAR para esse novo projeto de portlet vazio.
        1. Selecione Importar.
        2. Selecione Arquivo WAR e especifique o arquivo WAR exportado acima (Exportando Projeto para Arquivo WAR na Versão Anterior).
        3. Selecione o novo projeto de portlet vazio.
        4. Selecione Sobrescrever Recursos Existentes Sem Aviso.
        5. Não selecione Excluir Projeto na Sobreposição.
    3. 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.

    4. 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.


    Migrando Portlets do WebSphere Portal V4.2 para V5.x

    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:

    1. Migre os projetos de portlets do Portal V4.2 para os projetos de portlets do Portal V5.x:
      1. Clique com botão direito do mouse no projeto de aplicativo do portlet que deseja migrar.
      2. Selecione Propriedades -> API do Portlet para abrir a página API do Portlet.
      3. Selecione WebSphere Portal Versão 5.x na lista drop-down Nível de API do Portlet.
      4. 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.
    2. 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.
      1. Se o projeto de portlet migrado estiver associado somente ao projeto do aplicativo corporativo, proceda da seguinte forma:
        1. Feche todos os editores do workbench.
        2. Clique com o botão direito do mouse no projeto do aplicativo corporativo ao qual o projeto de portlet migrado está associado.
        3. Selecione Migrar -> Assistente para Migração do J2EE e clique em Avançar.
        4. Selecione J2EE Versão 1.3 e WebSphere Portal como o servidor de destino.
        5. Clique em Concluir.
      2. 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.
        1. Remova o módulo do projeto do portlet migrado do projeto do aplicativo corporativo.
          1. Expanda o projeto do aplicativo corporativo e selecione o descritor de implementação.
          2. Selecione Open With -> Deployment Descriptor Editor.
          3. Selecione a guia Módulo. Na página Módulo do editor, selecione o arquivo WAR do projeto do portlet migrado.
          4. Clique em Remover.
          5. Selecione Arquivo -> Salvar para salvar as alterações.
        2. Crie um novo projeto do aplicativo corporativo e inclua o projeto de portlet nele.
          1. Selecione Arquivo -> Novo -> Projeto.
          2. Selecione a caixa de opções Mostrar Todos os Assistentes.
          3. Expanda o J2EE e selecione Projeto do Aplicativo Corporativo.
          4. 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.
          5. 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.


    Atualizando Recursos de Tempo de Execução Faces em um Projeto de Portlet

    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:

    1. 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).
    2. 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.
    3. Clique em um dos seguintes:
    4. 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:

    1. Importe um projeto de portlet existente com conteúdo do Faces para um espaço de trabalho Rational Application Developer V6.0.1.
    2. 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.
    3. No Explorer do Projeto, clique com o botão direito do mouse no projeto JSFP601 e selecione Properties (Propriedades) no menu.
    4. 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.
    5. Para cada projeto Faces existente que deseja atualizar, faça o seguinte:
      1. 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
      2. 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.
      3. 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.
      4. 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>
        
    6. Exclua o projeto de portlet JSFP601.

    Capítulo 6. Alterações nos Ambientes de Teste do WebSphere

    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:

    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