IBM Rational Web 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 Web Developer V6.0

    Capítulo 3. 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 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
  • 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 Web Developer V6.0
  • Capítulo 4. 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 Site Developer V5.1.x para o Rational Web Developer V6.0.

    As informações adicionais podem ser localizadas nos seguintes tópicos:

    As informações sobre a utilização do Rational Web Developer podem ser encontradas na ajuda on-line.

    Consulte www.ibm.com/developerworks/rational para obter a documentação atualizada.

    Para obter informações sobre como migrar de versões anteriores do WebSphere Studio para a v5.x ou migrar do VisualAge para Java para o WebSphere Studio, vá para o endereço www.ibm.com/software/awdtools/studioappdev/support/ e procure o "guia de migração".

    Para migrar do WebSphere Studio V5.1.x:

    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 Web 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 Web Developer, será solicitada a confirmação de que você deseja utilizar um espaço de trabalho denominado rationalsdp6.0\workspace. Ou seja, a caixa de diálogo Ativador do Espaço de Trabalho aponta para o diretório que não é seu espaço de trabalho do WebSphere Studio. Para explorar o novo ambiente antes de migrar seu espaço de trabalho antigo, aceite o padrão ou especifique algum outro novo nome de diretório ao iniciar o Rational Web Developer. Você pode fazer isso, por exemplo, para que possa criar um ou mais projetos de teste, ler sobre o que há de novo, (Ajuda -> Bem-vindo), executar alguns dos novos tutoriais (Ajuda -> Tutorials Gallery) ou fazer experiências com algumas das novas amostras (Ajuda -> Samples Gallery).
    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 Web Developer com o espaço de trabalho antigo. Um indicador de progresso confirma que seus projetos estão sendo migrados automaticamente.

        Notas: Durante a migração do espaço de trabalho, uma caixa de diálogo Problemas é aberta com a mensagem Não foi possível restaurar o layout do workbench. Razão: Ocorreram problemas na restauração do workbench. As mensagens de erro não têm nenhum impacto na migração bem-sucedida do espaço de trabalho. Observe o nome da perspectiva que não pôde ser restaurada clicando no botão Detalhes na caixa de diálogo de erro e, em seguida, clique em OK para fechar a caixa de diálogo.

        Para restaurar a perspectiva:

        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 Web Developer V6.0. Todos os projetos EGL são migrados com segurança sem essa perspectiva no Rational Web Developer V6.0. Faça o seguinte se tiver utilizado a perspectiva da Web do EGL:
        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 Web 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 Web Developer V6.0 utilizando o recurso Intercâmbio de Projetos são automaticamente migrados para a V6.0. O recurso Intercâmbio de Projetos estava disponível no WebSphere Studio V5.1.2 e era um plug-in opcional para a V5.1.1.

      Notas:

      Importante:

    6. O Driver JDBC de Rede do DB2 não é suportado no Rational Web Developer V6.0. Se tiver criado conexões JDBC utilizando o driver JDBC de Rede do DB2, não será possível reconectar ao Rational Web Developer V6.0. Será necessário alterar a conexão para utilizar um dos drivers JDBC suportados. Consulte a ajuda on-line para obter informações adicionais sobre os drivers JDBC suportados na V6.0.
    7. Se você tiver o conteúdo de arquivos da Web ou XML migrado a partir do WebSphere Studio Site Developer V5.1.x que utilizou o conjunto de caracteres Shift_JIS e incluiu caracteres selecionados do fornecedor, será necessário especificar o conjunto de caracteres Windows-31J.
    8. Se você tiver instalado plug-ins de fornecedores com o WebSphere Studio Site Developer V5.1.x, será necessário obter os plug-ins correspondentes para a V6.0 e reinstalá-los.
    9. Se você utilizar recursos que exijam o Agent Controller, faça seu upgrade instalando a versão fornecida com o Rational Web Developer. Para obter detalhes, consulte o Guia de Instalação.
    10. 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 Web Developer, ele é automaticamente migrado. Depois de migrar um espaço de trabalho, ele não poderá mais ser aberto no WebSphere Studio Site Developer. Entretanto, os projetos no espaço de trabalho da V6.0 ainda podem ser compartilhados com o WebSphere Studio V5.1.x, utilizando um sistema SCM (Source Code Management) (como o Rational ClearCase), importando e exportando o projeto utilizando o Intercâmbio de Projetos ou importando archives e exportando projetos. Importante: Os aplicativos de portlet do Portal Toolkit V5.0.2.2 que forem migrados para o Portal Tools no Rational Web Developer V6.0 não serão compatíveis com releases anteriores.

    Nota:
    O seguinte não se aplica a projetos de aplicativos de portlets.

    Os projetos V5.1.x existentes que são carregados para a V6.0 a partir de um sistema SCM ou de outro desenvolvedor utilizando o Intercâmbio de Projetos serão compatíveis para compartilhamento com a V5.1.x desde que você não execute nenhuma das ações a seguir:

    Um arquivo .compatibility é criado automaticamente no diretório project quando um projeto V5.1.x é aberto no espaço de trabalho do Rational Web Developer V6.0. O arquivo .compatibility é utilizado pelo Rational Web Developer para rastrear os timestamps dos recursos do projeto quando esses recursos são migrados. Você não deve editá-lo ou excluí-lo.

    Para obter informações sobre como desativar a compatibilidade com o WebSphere Studio Site Developer V5.1.x, consulte Desativando a Compatibilidade com o WebSphere Studio V5.1.x.

    Considerações do Eclipse

    Esta versão do Rational Web Developer é baseada no Eclipse V3.0. Se você desenvolver seus próprios plug-ins, você deve ler sobre alterações da plataforma antes de migrar.

    Para obter detalhes, consulte o arquivo leia-me no subdiretório eclipse\readme do local da instalação do Rational Web Developer V6.0. As seções do arquivo leia-me que são interessantes para a migração são:

    Compatibilidade do Projeto do J2EE

    A compatibilidade com releases futuros de projetos criados no WebSphere Studio V5.1.x com o Rational Web Developer V6.0 é ativada por meio de metadados que são incluídos automaticamente nos arquivos .project, quando você migrar seu espaço de trabalho V5.1.x. De forma semelhante, se você criar um novo módulo ou aplicativo J2EE 1.2 ou 1.3 no Rational Web Developer V6.0, os metadados da compilação são automaticamente incluídos no arquivo .project para compatibilidade com a V5.1.x. Não edite ou exclua essas informações diretamente.

    Nota:
    Esses metadados de compatibilidade farão com que mensagens sobre "construtores ausentes" sejam exibidas ou registradas quando um novo módulo ou aplicativo J2EE 1.2 e J2EE 1.3 criado na V6.0 for utilizado no WebSphere Studio Site Developer V5.1.X, onde os construtores V6.0 não estão disponíveis. Essas mensagens são normais; você pode ignorá-las.

    Desde que esses metadados de compatibilidade estejam presentes, serão exibidas mensagens sobre "construtores ausentes" quando projetos do Rational Web Developer V6.0 forem carregados no WebSphere Studio V5.1.x. Segue um exemplo de uma mensagem de "construtor ausente":

    !ENTRY org.eclipse.core.resources 2 1 Sep 06, 2004 19:55:20.592
    !MESSAGE Ignorando construtor com.ibm.wtp.j2ee.LibCopyBuilder para projeto Test60EARWeb.
    O construtor está faltando na instalação ou pertence a uma natureza de projeto
    ausente ou desativada. 
    

    Essas mensagens são normais; você pode ignorá-las. Quando você tiver certeza de que não precisa mais trabalhar com um determinado projeto no WebSphere Studio V5.1.x, é possível parar as mensagens, desativando a compatibilidade com releases anteriores para o projeto.

    Importante: Novos projetos de especificação J2EE 1.2 ou 1.3 criados na V6.0 são compatíveis com o WebSphere Studio V5.1.x, mas depois do projeto ser carregado no WebSphere Studio, há algumas etapas manuais necessárias antes de você poder trabalhar com o projeto. Essas etapas são necessárias porque os destinos do tempo de execução em novos projetos de especificação J2EE 1.2 ou 1.3 criados na 6.0 não são diretamente compatíveis com releases anteriores dos servidores de destino na V5.1.x. As etapas manuais após o carregamento de um novo projeto V6.0 na V5.1.x são as seguintes:

    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 Web Developer V6.0 e o WebSphere Studio Site Developer V5.1.x. Depois das alterações serem consolidadas no sistema SCM, os projetos do J2EE podem interoperar entre a V5.1.x e a V6.0, utilizando um sistema SCM.
      Nota:
      Se o servidor de destino for definido novamente no Rational Web Developer V6.0, a compatibilidade do projeto do J2EE será perdida e precisará ser restabelecida.

    Desativando a Compatibilidade com o WebSphere Studio V5.1.x

    A compatibilidade com o WebSphere Studio Site Developer V5.1.x pode ser totalmente removida de um projeto do aplicativo corporativo criado no Rational Web Developer V6.0 ou de um projeto do aplicativo corporativo migrado de uma versão anterior do WebSphere Studio. Você deve desativar a compatibilidade com o WebSphere Studio V5.1.x, somente se tiver certeza de que o projeto do aplicativo corporativo não deve mais interoperar ou ser compatível com a V5.1.x.

    Para remover a compatibilidade com WebSphere Studio Site Developer V5.1.x:

    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 Site 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 Site Developer V5.1.x foram atualizado para Rational Web Developer V6.0.1. Se você quiser continuar o desenvolvimento em projetos da Web criados com essa versão anterior do produto, recomendamos a atualização dos recursos de tempo de execução Faces para os níveis mais recentes.

    No Rational Web Developer V6.0.1, as atualizações dos recursos de tempo de execução Faces ocorrem automaticamente quando um projeto da Web é importado ou um espaço de trabalho, que contém recursos desatualizados, é aberto. Depois de importar um projeto da Web ou abrir um espaço de trabalho do WebSphere Studio Site Developer V5.1.x no Rational Web Developer V6.0.1, você receberá um aviso para atualizar os recursos de tempo de execução Faces para os níveis mais recentes.

    Atualizando automaticamente os recursos de tempo de execução

    Para atualizar os recursos de tempo de execução automaticamente para um projeto da Web:

    1. Importe um projeto da Web (ou um espaço de trabalho) com conteúdo do Faces do WebSphere Studio Site Developer V5.1.x. A janela Project Migration (Migração de Projetos) é aberta.
      Nota:
      Se a janela Project Migration (Migração de Projetos) não for aberta, sua configuração de preferência automática de construção será provavelmente desativada. No Explorer do Projeto, clique com o botão direito do mouse no projeto da Web e selecione Build (Construir) -> Project (Projeto); o processo de reconstrução de um projeto é aberto na janela Project Migration (Migração de Projetos).
    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 Web 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 Site Developer V5.1.x foram atualizado para o Rational Web Developer V6.0.1. Se você quiser continuar o desenvolvimento em projetos da Web criados com essa versão anterior do produto, recomendamos a atualização dos recursos de tempo de execução Faces Client para os níveis mais recentes.

    No Rational Web Developer V6.0.1, as atualizações dos recursos de tempo de execução Faces Client ocorrem automaticamente quando um projeto da Web é importado ou um espaço de trabalho, que contém recursos desatualizados, é aberto. Depois de importar um projeto da Web ou abrir um espaço de trabalho do WebSphere Studio Site Developer V5.1.x Rational Web Developer V6.0.1, você receberá um aviso para atualizar os recursos de tempo de execução Faces Client para os níveis mais recentes.

    Atualizando automaticamente os recursos de tempo de execução

    Para atualizar os recursos de tempo de execução Faces Client automaticamente para um projeto da Web:

    1. Importe um projeto da Web (ou um espaço de trabalho) com conteúdo do Faces Client do WebSphere Studio Site Developer V5.1.x. A janela Project Migration (Migração de Projetos) é aberta.
      Nota:
      Se a janela Project Migration (Migração de Projetos) não for aberta, sua configuração de preferência automática de construção será provavelmente desativada. No Explorer do Projeto, clique com o botão direito do mouse no projeto da Web e selecione Build (Construir) -> Project (Projeto); o processo de reconstrução de um projeto é aberto na janela Project Migration (Migração de Projetos).
    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 Web Developer V6.0 incluirá a "/" quando um novo projeto Struts for criado; contudo, ela deve ser incluída manualmente durante a migração do WebSphere Studio V5.1x.

    Siga estas etapas para corrigir, no V6.0, o descritor de implementação de um projeto da Web Struts criado no WebSphere Studio v5.1.x:

    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 Web 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 Web 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 Web Developer V6.0. Você precisará estar ciente dessas alterações, para utilizar essas ferramentas com seus projetos depois da migração. Pode ser necessário alterar ou restaurar as configurações.

    Migrando Espaços de Trabalho e Configurações de Ativação

    Quando um espaço de trabalho V5.1.x do WebSphere Studio Site Developer é aberto no Rational Web Developer V6.0, as seguintes configurações de ativação do depurador associadas ao espaço de trabalho não serão migradas automaticamente:

    Depurar Visualizações

    As visualizações Armazenamento e Mapeamento do Armazenamento não existem mais. Elas foram substituídas pelas visualizações Memória e Apresentação de Memória.

    O Depurador XSLT

    Esse depurador foi substituído na V6.0 e muitas de suas visualizações e ações foram alteradas de forma significativa. Para obter informações adicionais, consulte a documentação do depurador XSLT no centro de informações.

    Uma das alterações mais significativas no depurador XSLT é sua dependência no JRE instalado com o Rational Web Developer V6.0. Se você migrar um espaço de trabalho do WebSphere Studio Site Developer V5.1.x, será necessário modificar o JRE instalado para apontar para o local correto antes de poder ativar uma sessão de depuração XSLT para ele. Para fazer isso, é possível executar uma das seguintes ações:


    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 Web 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 Web 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 Web Developer V6.0

    Os recursos de tempo de execução JavaServer Faces e Faces Client fornecidos originalmente no Rational Web Developer V6.0 foram atualizados para o Rational Web Developer V6.0.1. Se você quiser continuar o desenvolvimento em projetos da Web criados com essa versão anterior do produto, recomendamos a atualização dos recursos de tempo de execução Faces e Faces Client para os níveis mais recentes.

    No Rational Web Developer V6.0.1, as atualizações dos recursos de tempo de execução Faces e Faces Client ocorrem automaticamente quando um projeto da Web é importado ou um espaço de trabalho, que contém recursos de tempo de execução Faces e Faces Client desatualizados, é aberto. Depois de importar um projeto da Web ou abrir um espaço de trabalho do Rational Web Developer V6.0 para o Rational Web Developer V6.0.1, você receberá um aviso para atualizar esses recursos de tempo de execução para os níveis mais recentes.

    Atualizando automaticamente os recursos de tempo de execução

    Para atualizar os recursos de tempo de execução Faces e Faces Client automaticamente para um projeto da Web:

    1. Importe um projeto da Web (ou um espaço de trabalho) com conteúdo do Faces ou Faces Client do Rational Web Developer V6.0. A janela Project Migration (Migração de Projetos) é aberta.
      Nota:
      Se a janela Project Migration (Migração de Projetos) não for aberta, sua configuração de preferência automática de construção será provavelmente desativada. No Explorer do Projeto, clique com o botão direito do mouse no projeto da Web e selecione Build (Construir) -> Project (Projeto); o processo de reconstrução de um projeto é aberto na janela Project Migration (Migração de Projetos).
    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. Migrando Projetos do J2EE

    O Assistente para Migração do J2EE foi atualizado no Rational Web Developer V6.0 para migrar projetos do J2EE para o nível de especificação J2EE 1.4. O Assistente de Migração J2EE suporta migração das especificações J2EE 1.2 e 1.3 para o nível de especificação J2EE 1.4 para todos os tipos de módulo J2EE.

    Consulte Migração do Nível de Especificação J2EE 1.3 para 1.4 e Migração do Nível de Especificação J2EE 1.2 para 1.4 para obter detalhes sobre a migração dos artefatos do nível de especificação J2EE 1.3 e 1.2 para o nível de especificação J2EE 1.4.

    Nota:
    Antes de utilizar o Assistente para Migração do J2EE, é altamente recomendável executar as seguintes etapas:

    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 Web Developer V6.0.

    Consulte Migração do Nível de Especificação J2EE 1.3 para 1.4 e Migração do Nível de Especificação J2EE 1.2 para 1.4 para obter detalhes sobre a migração dos artefatos do nível de especificação J2EE 1.3 e 1.2 para J2EE 1.4.


    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 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 3, Migrando Projetos do J2EE.

    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 Web Developer V6.0

    Foram feitas alterações no Assistente para Migração do J2EE no Rational Web Developer V6.0 comuns à migração de todos os níveis de especificação J2EE.

    Migração da Estrutura do Projeto é Opcional

    Do WebSphere Studio V5.1.x até V5.1.2, a migração da estrutura do projeto ocorre de forma simultânea com a migração do nível de especificação J2EE. A migração da estrutura de projeto não foi opcional ao migrar os níveis de especificação J2EE.

    No Assistente para Migração do J2EE no Rational Web Developer V6.0, Migrar Estrutura do Projeto é uma seleção opcional separada de Migrar Nível de Especificação J2EE do Projeto. A migração do nível de especificação J2EE e a migração da estrutura de projeto podem ser executadas de forma independente.

    Servidor de Destino Requerido

    No Rational Web Developer V6.0, projetos do J2EE novos e existentes migrados para um nível de especificação J2EE mais alto requerem que um servidor de destino seja definido no projeto. Destino do Servidor é o mecanismo padrão de como o caminho de classe é definido em um projeto do J2EE na V6.0. Para obter informações sobre como definir um servidor de destino utilizando o Assistente para Migração do J2EE, consulte a ajuda on-line.


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

    No Rational Web Developer V6.0, os ambiente de teste do WebSphere Application Server fornecidos com o produto foram alterados em relação àqueles incluídos em edições anteriores do WebSphere Studio Site Developer.

    Segue um resumo das alterações nos ambientes de teste do WebSphere Application Server no Rational Web Developer V6.0:

    A tabela a seguir mostra os níveis do ambiente de teste do WebSphere Application Server com as diferentes versões do WebSphere Studio Site Developer e do Rational Web Developer.

    Tabela 2. Ambientes de Teste do WebSphere Application Server no WebSphere Studio Site Developer e Rational Web Developer


    WebSphere Application Server V4.x AEs WebSphere Application Server V5.x Base WebSphere Application Server Express V5.x WebSphere Application Server V6.0
    WebSphere Studio Site Developer V5.1 V4.0.6 V5.0.2 V5.0.2 N/A
    WebSphere Studio Site Developer V5.1.1 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419, V5.1 V5.0.2 & V5.1 N/A
    WebSphere Studio Site Developer V5.1.2 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419, V5.1.0.3 V5.0.2 & V5.1.0.3 N/A
    Rational Web Developer V6.0 N/A V5.0.x, V5.1.1 V5.0.2 e V5.1.1 V6.0

    Copyright e Avisos