1. Primeiro, observe o empacotamento de seu aplicativo e suas dependências. Consulte a: Seção 3.1.2.3, “Atualização das Dependências do Aplicativo devido às Alterações do Carregamento da Classe” para maiores informações.
2. Caso o seu aplicativo realize o logon, será necessário especificar corretamente as dependências do módulo. Consulte a: Seção 3.1.4.1, “Modificação das Dependências de Registro em Log” para maiores informações.
3. A estrutura do empacotamento de seu EAR ou WAR talvez precise ser alterada devido às alterações de carregamento de classe modular. Consulte a: Seção 3.1.5.1, “Modificação do Empacotamento dos EARS e WARs” para maiores informações.

Procedimento 3.1. Compreendendo as Dependências do Módulo

1. Compreendendo as dependências implícitas

   Os implantadores com o servidor adicionam automaticamente, e de forma implícita, algumas dependências de módulo comumente usadas como o javax.api e sun.jdk. Isto permite que as classes sejam visíveis à implantação no período de execução reduzindo a tarefa do desenvolvedor de adicionar explicitamente dependências. Consulte as Dependências de Módulo Implícitas no capítulo nomeado Carregamento de Carga e Módulo no Guia de Desenvolvimento para o JBoss EAP 6 https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ para maiores informações.

2. Compreendendo as dependências explícitas

   Os módulos devem ser especificados explicitamente para outras classes, do contrário as dependências ausentes resultarão em implantação ou erros do período de execução. Caso falte uma dependência, traços ClassNotFoundExceptions ou NoClassDefFoundErrors poderão ser observados no log do servidor. Caso mais de um módulo carregar o mesmo JAR ou um módulo carregar uma classe que estende uma classe carregada por um módulo diferente, traços ClassCastExceptions poderão ser vistos no servidor do log. Modifique o MANIFEST.MF ou crie um arquivo do descritor de implantação específico do JBoss jboss-deployment-structure.xml para especificação explícita de dependências. Refira-se à Visão Geral do Carregamento de Classe e Módulos no capítulo nomeado Carregamento de Classe e Módulo no Guia de Desenvolvimento para o JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

Procedimento 3.2. Altere a Localização das Propriedades ResourceBundle

1. Caso esteja implantando um arquivo WAR, essas propriedades devem ser empacotadas na pasta WEB-INF/classes/ do WAR.
2. Caso deseje disponibilizar essas propriedades a todos os componentes num EAR, elas devem ser empacotadas à raiz do JAR na pasta lib/ do EAR.

Procedimento 3.3. Criação de um Módulo Personalizado

1. Crie e preencha a estrutura do diretório module/.
   1. Crie uma estrutura de diretório sob o diretório EAP_HOME/module para conter os arquivos e JARs. Por exemplo:

      $ cd EAP_HOME/modules/ 
      $ mkdir -p myorg-conf/main/properties

   2. Mova os arquivos de propriedades ao diretório EAP_HOME/modules/myorg-conf/main/properties/ criado na etapa anterior.
   3. Crie um arquivo module.xml no diretório EAP_HOME/modules/myorg-conf/main/ contendo o seguinte XML:

      <module xmlns="urn:jboss:module:1.1" name="myorg-conf">
          <resources>
              <resource-root path="properties"/>
          </resources>
      </module>
      
      

2. Modifique o subsistema ee no arquivo de configuração do servidor. Você pode usar o JBoss CLI ou pode editar manualmente o arquivo.
   • Siga as seguintes etapas para modificar o arquivo de configuração do servidor usando o JBoss CLI.
     1. Inicie o servidor e conecte-se ao Management CLI.
        • Insira a seguinte linha de comando para o Linux:

          $ EAP_HOME/bin/jboss-cli.sh --connect
          

        • Insira a seguinte linha de comando para o Windows:

          C:\>EAP_HOME\bin\jboss-cli.bat --connect
          

        Você deverá observar a seguinte resposta:

        Conectado ao controlador autônomo no localhost:9999

     2. Digite o seguinte na linha de comando para criar o elemento myorg-conf <global-modules> no subsistema ee:

        /subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])
        

        Você deverá ver o seguinte resultado:

        {"outcome" => "success"}
        

   • Siga essas etapas caso prefira editar manualmente o arquivo da configuração do servidor.
     1. Interrompa o servidor e abra o arquivo de configuração do servidor num editor de texto. Caso esteja executando um servidor autônomo, o arquivo será o EAP_HOME/standalone/configuration/standalone.xml ou caso esteja executando um managed domain, o arquivo será o EAP_HOME/domain/configuration/domain.xml.
     2. Encontre o subsistema ee e adicione o módulo global para myorg-conf. Segue abaixo uma amostra do elemento do subsistema ee modificado para inclusão do elemento myorg-conf:

        <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
            <global-modules>
                <module name="myorg-conf" slot="main" />            
            </global-modules>
        </subsystem>
        
        

3. Assumindo que você copiou um arquivo nomeado my.properties à localização de módulo correta, você poderá agora carregar os arquivos de propriedades usando o código similar ao seguinte:

   Thread.currentThread().getContextClassLoader().getResource("my.properties");
   

Procedimento 3.4. Atualização do código de registro de log do aplicativo

1. Seção 3.1.4.2, “Atualização do Código do Aplicativo para Frameworks de Registro de Log de Terceiros”
2. Seção 3.1.4.3, “Modificação do Código para Uso do Novo Framework de Registro de Log do JBoss”

Procedimento 3.5. Configuração do JBoss EAP 6 para uso de um arquivo log4j.properties ou log4j.xml

1. Criação de um jboss-deployment-structure.xml com o seguinte conteúdo:

   <jboss-deployment-structure>
       <deployment>
           <!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
           <exclusions>
               <module name="org.apache.log4j" />
           </exclusions>
       </deployment>
   </jboss-deployment-structure>
   
   

2. Posicione o arquivo jboss-deployment-structure.xml, tanto em seu diretório META-INF/ ou no diretório WEB-INF/, caso esteja implantando um WAR. Do contrário, posicione-o no diretório META-INF/ caso esteja implantando um EAR. Caso a sua implantação incluir implantações filho dependente, o módulo deve ser também excluído para cada subimplantação.
3. Adicione o arquivo log4j.properties ou log4j.xml no diretório lib/ de seu EAR ou no diretório WEB-INF/classes/ de sua implantação WAR. Caso deseje posicionar o arquivo no diretório lib/ de seu WAR, o caminho <resource-root> deve ser especificado no arquivo jboss-deployment-structure.xml.

   <jboss-deployment-structure>
       <deployment>
           <!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
           <exclusions>
               <module name="org.apache.log4j" />
           </exclusions>
           <resources>
               <resource-root path="lib" />
           </resources>
       </deployment>
   </jboss-deployment-structure>
   
   

4. Inicie o servidor do JBoss EAP 6 com o seguinte argumento para evitar que um ClassCastException apareça no console no momento de implantação de seu aplicativo:

   -Dorg.jboss.as.logging.per-deployment=false

5. Implante seu aplicativo.

Procedimento 3.6. Configuração das Dependências de Logon para o JBoss EAP 6.3 ou versões mais recentes

1. Inicie o servidor do JBoss EAP 6 com o seguinte argumento para evitar que um ClassCastException apareça no console no momento de implantação de seu aplicativo:

   -Dorg.jboss.as.logging.per-deployment=false

2. Abra um terminal e conecte-se ao Management CLI.
   • Insira a seguinte linha de comando para o Linux:

     $ EAP_HOME/bin/jboss-cli.sh --connect
     

   • Insira a seguinte linha de comando para o Windows:

     C:\>EAP_HOME\bin\jboss-cli.bat --connect
     

3. Modifique o atributo add-logging-api-dependencies no subsistema de logon.
   Este atributo controla se o contêiner adiciona implicitamente as dependências API de logon as suas implantações.

   • Caso determinado para true, que é o default, todas as dependências API de logon implícitas serão adicionadas.
   • Caso determinado para false, as dependências não são adicionadas as suas implantações.
   Este atributo deve ser determinado para false usando o seguinte comando, com o objetivo de excluir as dependências do framework de logon de terceiros:

   /subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)

   Este comando adiciona o elemento <add-logging-api-dependencies> ao subsistema logging do arquivo de configuração standalone.xml.

   <subsystem xmlns="urn:jboss:domain:logging:1.4">
       <add-logging-api-dependencies value="false"/>
       ....
   </subsystem>
   
   

4. Implante seu aplicativo.

Procedimento 3.7. Modifique o Código e Dependências para Uso do JBoss logging Framework

1. Alteração de suas importações e código de registro em log

   Segue abaixo uma amostra do código que usa o novo framework do JBoss Logging:

   import org.jboss.logging.Level;
   import org.jboss.logging.Logger;
   
   private static final Logger logger = Logger.getLogger(MyClass.class.toString());
   
   if(logger.isTraceEnabled()) {
       logger.tracef("Starting...", subsystem);
   }
   

2. Adição de dependência de registro em log

   O JAR contendo as classes do JBoss Logging está localizado no módulo nomeado org.jboss.logging. O seu arquivo MANIFEST-MF deve parecer com o seguinte:

   Manifest-Version: 1.0
   Dependencies: org.jboss.logging
   

   Por favor consulte a Seção 3.1.2.3, “Atualização das Dependências do Aplicativo devido às Alterações do Carregamento da Classe” e a Seção 4.2.1, “Depuração e Solução dos Problemas de Migração” para maiores informações sobre como encontrar a dependência do módulo.

Procedimento 3.8. Modificação do empacotamento do arquivo

1. Empacotamento do WAR

   O WAR é um módulo único e todas as classes no WAR são carregadas com o mesmo carregador de classe. Isto significa que as classes empacotadas no diretório WEB-INF/lib/ são tratadas da mesma forma que as classes no diretório WEB-INF/classes.

2. Empacotamento de um EAR

   Um EAR consiste de módulos múltiplos. O diretório EAR/lib/ é um módulo único e cada WAR ou subimplantação EJB jar no EAR é um módulo separado. As classes não possuem acesso às classes em outros módulos com o EAR, a não ser que as dependências tenham sido definidas. As subimplantações sempre possuem uma dependência automática no módulo pai que as fornecem acesso às classes no diretório EAR/lib/. No entanto, as subimplantações nem sempre possuem uma dependência automática para permitir que se acessassem entre si. Este comportamento é controlado pela configuração do elemento <ear-subdeployments-isolated> na configuração do subsistema ee, conforme abaixo:

   <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
     <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
   </subsystem>
   

   Por default, isto é configurado para falso, permitindo que as subimplantações vejam as classes pertencentes às demais subimplantações com o EAR.
   Refira-se ao capítulo nomeado no carregamento da classe ao capítulo nomeado Carregamento de Classe e Módulos no Guia de Desenvolvimento para o JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

1. Caso seu aplicativo use a fonte de dados, consulte a: Seção 3.1.6.2, “Atualização da Configuração da Fonte de Dados”.
2. Caso o seu aplicativo use o JPA e empacote os Hibernate JARs, consulte a: Seção 3.1.6.4, “Configuração da Fonte de Dados para o Hibernate ou JPA” para opções de migração.
3. Caso seu aplicativo use um adaptador de recurso, consulte a: Seção 3.1.6.5, “Atualização da Configuração do Adaptador de Recurso”.
4. Revise a seguinte informação de como configurar as alterações para a segurança básica na: Seção 3.1.7.1, “Configuração das Alterações de Segurança do Aplicativo”.

Procedimento 3.9. Instalação e Configuração do JDBC Driver

1. Instale o JDBC Driver.

   1. Instale o JDBC Driver como uma implantação.

      Esta é a maneira recomendada de instalação do driver. Quando o JDBC driver for instalado como uma implantação, ele é implantado como um JAR regular. Caso a instância do JBoss EAP 6 estiver sendo executada como um servidor autônomo, copie o JDBC 4.0 compatível com o diretório EAP_HOME/standalone/deployments/. Para um managed domain, o Management Console ou Management CLI deve ser usado para implantar o JAR aos grupos do servidor.
      Segue abaixo uma amostra de um MySQL JDBC driver instalado como implantação ao servidor autônomo:

      $cp mysql-connector-java-5.1.15.jar EAP_HOME/standalone/deployments/

      Qualquer driver compatível com o JDBC 4.0 é automaticamente reconhecido e instalado no sistema pelo nome e versão. Um JAR compatível com o JDBC 4.0 contém um texto com arquivo nomeado META-INF/services/java.sql.Driver que especifica o(s) nome(s) da classe do driver. Caso o driver não for compatível com o JDBC 4.0, ele pode ser implantável em uma das seguintes maneiras:

      • Crie e adicione o arquivo java.sql.Driver ao JAR sob o caminho META-INF/services/. Esse arquivo deve conter o nome de classe do driver, por exemplo:

        com.mysql.jdbc.Driver

      • Crie um arquivo java.sql.Driver no diretório de implementação. Para uma instância do JBoss EAP 6 executando como um servidor autônomo, o arquivo deve ser posicionado no: EAP_HOME/standalone/deployments/META-INF/services/java.sql.Driver. Caso o servidor estiver num managed domain, o uso do Management Console ou do Managment CLI deve ser aplicado para implantar o arquivo.
      Os aspectos positivos desta abordagem são:

      • Este é o método mais simples uma vez que não há necessidade de definir um módulo.
      • Quando o servidor estiver executando num managed domain, as implantações que usam esta abordagem são propagadas automaticamente a todos os servidores no domain. Isto significa que o administrador não precisa distribuir o driver JAR manualmente.

      Os aspectos negativos desta abordagem são:

      • Caso o JDBC driver consistir de mais de um JAR, por exemplo o driver JAR mais o JAR da licença de dependência JAR ou JAR de localização, o driver não pode ser instalado como implantação. O JDBC deve ser instalado como um módulo core.
      • Caso o driver não for compatível com o JDBC 4.0, um arquivo deve ser criado contendo o(s) nome(s) da classe do driver e deve ser importado num JAR ou sobreposto no diretório deployments/.

   2. Instale o JDBC Driver como um módulo core.

      Para instalar um JDBC driver como um módulo core, uma estrutura do caminho do arquivo sob o diretório EAP_HOME/modules/ deve ser criada. Esta estrutura contém o JDBC driver JAR, qualquer licença do fornecedor adicional ou JARs de localização e um arquivo module.xml para definição do módulo.

      • Instale o MySQL JDBC Driver como módulo core

        1. Crie uma estrutura de diretório EAP_HOME/modules/com/mysql/main/
        2. No subdiretório main/, crie um arquivo module.xml contendo a seguinte definição do módulo para o MySQL JDBC driver:

           <?xml version="1.0" encoding="UTF-8"?>
           <module xmlns="urn:jboss:module:1.0" name="com.mysql">
           <resources>
               <resource-root path="mysql-connector-java-5.1.15.jar"/>
           </resources>
           <dependencies>
               <module name="javax.api"/>
           </dependencies>
           </module>
           
           
           

           O nome do módulo, "com.mysql", coincide com a estrutura do diretório para esse módulo. O elemento <dependencies> é usado para especificar as dependências do módulo em outros módulos. Neste caso, como é o caso em todas as fontes de dados JDBC, isto é dependente do Java JDBC APIs que é definido em outro módulo nomeado javax.api. Este módulo está localizado sob o diretório modules/system/layers/base/javax/api/main/.

           Nota

           Certifique-se de que NÃO possui espaço no início do arquivo module.xml ou um erro "Novas dependências ausentes/não satisfatórias" para este driver será obtido.
        3. Copie o MySQL JDBC driver JAR ao diretório EAP_HOME/modules/com/mysql/main/:

           $ cp mysql-connector-java-5.1.15.jar EAP_HOME/modules/com/mysql/main/

      • Instale o IBM DB2 JDBC driver e JAR de licença como um módulo core.

        Esta amostra é fornecida para apenas demonstrar como implantar drivers que requerem JARs além do JDBC Driver JAR.
        1. Crie a estrutura do diretório EAP_HOME/modules/com/ibm/db2/main/.
        2. No subdiretório main/ crie um arquivo module.xml contendo a seguinte definição do módulo para o IBM DB2 JDBC driver e licença:

           <?xml version="1.0" encoding="UTF-8"?>
           <module xmlns="urn:jboss:module:1.1" name="com.ibm.db2">
             <resources>
               <resource-root path="db2jcc.jar"/>
               <resource-root path="db2jcc_license_cisuz.jar"/>
             </resources>
             <dependencies>
               <module name="javax.api"/>
               <module name="javax.transaction.api"/>
             </dependencies>
           </module>
           
           

           Nota

           Certifique-se de que NÃO possui espaço no início do arquivo module.xml ou um erro "Novas dependências ausentes/não satisfatórias" para este driver será obtido.
        3. Copie o JDBC driver e a licença JAR ao diretório EAP_HOME/modules/com/ibm/db2/main/.

           $ cp db2jcc.jar EAP_HOME/modules/com/ibm/db2/main/
           $ cp db2jcc_license_cisuz.jar EAP_HOME/modules/com/ibm/db2/main/

      Os aspectos positivos desta abordagem são:

      • Esta é a única abordagem que funciona quando o JDBC driver consiste de mais de um JAR.
      • Com esta abordagem, os drivers que não são compatíveis com o JDBC 4.0 podem ser instalados sem modificar o driver JAR ou criando uma sobreposição de arquivo.

      Os aspectos negativos desta abordagem são:

      • É mais difícil configurar um módulo.
      • O módulo deve ser manualmente copiado para cada servidor executando num managed domain.

2. Configure a fonte de dados.

   1. Adicione o driver do banco de dados.

      Adicione o elemento <driver> ao elemento <drivers> de mesmo arquivo. Isto contém algumas das informações que foram definidas anteriormente no arquivo *-ds.xml.
      Primeiro determine se o driver JAR é compatível com o JDBC 4.0. Um JAR que é compatível com o JDBC 4.0 contém um arquivo META-INF/services/java.sql.Driver que especifica o nome de classe do driver. O servidor usa este arquivo para encontrar o nome da(s) classe(s) de driver no JAR. Um driver que é compatível com o JDBC 4.0 não requer um elemento <driver-class>, uma vez que ele já está especificado no JAR. Esta é uma amostra do elemento do driver para um JDBC 4.0 compatível com o driver MySQL:

      <driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"/>
      

      Um driver que não seja compatível com o JDBC 4.0 requer um atributo <driver-class> para identificar a classe do driver desde que não haja um arquivo META-INF/services/java.sql.Driver que especifique o nome da classe do driver. Segue abaixo uma amostra do elemento driver para o driver não compatível com o JDBC 4.0:

      <driver name="mysql-connector-java-5.1.15.jar" module="com.mysql">
      <driver-class>com.mysql.jdbc.Driver</driver-class></driver>
      

   2. Crie a fonte de dados.

      Crie um elemento <datasource> na seção <datasources> do arquivo standalone.xml. Este arquivo contém bastante informações da fonte de dados anteriormente definida no arquivo *-ds.xml.

      Importante

      O servidor deve ser interrompido antes de editar o arquivo de configuração do servidor para que sua alteração seja efetivada no reinício do servidor.
      Segue abaixo uma amostra de um elemento de fonte de dados MySQL no arquivo standalone.xml:

      <datasource jndi-name="java:/YourDatasourceName" pool-name="YourDatasourceName">
        <connection-url>jdbc:mysql://localhost:3306/YourApplicationURL</connection-url>
        <driver>mysql-connector-java-5.1.15.jar</driver>
        <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
        <pool>
          <min-pool-size>100</min-pool-size>
          <max-pool-size>200</max-pool-size>
        </pool>
        <security>
          <user-name>USERID</user-name>
          <password>PASSWORD</password>
        </security>
        <statement>
          <prepared-statement-cache-size>100</prepared-statement-cache-size>
          <share-prepared-statements/>
        </statement>
      </datasource>
      
      

3. Atualize as referências JNDI no código do aplicativo.

   Os nomes de pesquisa JNDI antigos no código fonte do aplicativo devem ser substituídos para uso dos nomes da fonte de dados padronizados do JNDI definidos anteriormente. Consulte a Seção 3.1.8.4, “Modificação do Aplicativo para Seguir as Novas Regras do JNDI Namespace” para maiores informações.
   Quaisquer anotações @Resource existentes devem ser também substituídas, das quais acessam a fonte de dados para uso do novo nome JNDI. Por exemplo:

   @Resource(name = "java:/YourDatasourceName").
   

Procedimento 3.10. Remoção do pacote Hibernate

1. Remova o Hibernate JARs de suas pastas da biblioteca do aplicativo.
2. Remova ou comente o elemento <hibernate.transaction.manager_lookup_class> em seu arquivo persistence.xml, uma vez que este elemento não é necessário.

Procedimento 3.11. Desabilitação das Verificações de Autorização Adicional

• As verificações de autorização adicional podem ser desabilitadas e continuarem usando as implantações PicktLink existentes, pelo uso de um dos seguintes métodos.

  • Determinação da Propriedade em todo o Sistema

    As verificações de autorização adicional podem ser desabilitadas ao nível do servidor pela determinação do valor do sistema de propriedade org.jboss.ws.cxf.disableHandlerAuthChecks para true. Este método afeta qualquer implantação realizada ao servidor do aplicativo.
    Consulte o tópico nomeado Configuração das Propriedades de Sistema usando o Management CLI no Guia de Configuração e Administração do JBoss EAP para maiores informações sobre como determinar uma propriedade de sistema.

  • Criação de uma Propriedade no Arquivo do Descritor do Web Services de Implantação

    As verificações de autorização no nível de implantação podem ser desabilitadas pela configuração do valor da propriedade org.jboss.ws.cxf.disableHandlerAuthChecks para true no arquivo jboss-webservices.xml.
    1. Crie um arquivo jboss-webservices.xml no diretório META-INF/ da implantação pela qual deseja desabilitar as verificações da autorização.
    2. Adicione o seguinte conteúdo:

       <?xml version="1.1" encoding="UTF-8"?>
       <webservices xmlns="http://www.jboss.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         version="1.2" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee">
         <property>
           <name>org.jboss.ws.cxf.disableHandlerAuthChecks</name>
           <value>true</value>
         </property>
       </webservices>
       

Procedimento 3.12. Modificação das pesquisas JNDI

1. Leia mais a respeito deste assunto na Seção 3.1.8.2, “Nomes do EJB JNDI Portátil ”
2. Seção 3.1.8.3, “Revisão das Regras JNDI Namespace”
3. Seção 3.1.8.4, “Modificação do Aplicativo para Seguir as Novas Regras do JNDI Namespace”

Procedimento 3.13. Configuração do Aplicativo

1. Copie o Hibernate 3 JARs requerido para sua biblioteca do aplicativo.

   Você pode estar apto a resolver o problema copiando o Hibernate 3 JARs específico que contém classes ausentes no diretório lib/ do aplicativo ou adicionando-as ao classpath usando algum outro método. Em alguns casos, isto pode resultar no ClassCastExceptions ou outros problemas de carregamento de classe devido ao uso misturado das versões Hibernate. Caso isto aconteça, você precisará usar a próxima abordagem.

2. Instrução do servidor para uso apenas das bibliotecas HIbernate 3.

   O JBoss EAP 6 permite você empacotar os jars do provedor de persistência Hibernate 3.5 (ou superior) com o aplicativo. Para direcionar o servidor para uso apenas das bibliotecas Hibernate 3 e excluir as bibliotecas do Hibernate 4, você precisa configurar o jboss.as.jpa.providerModule para hibernate3-bundled no persistence.xml, conforme abaixo:

   <?xml version="1.0" encoding="UTF-8"?>
   <persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
       <persistence-unit name="plannerdatasource_pu">
           <description>Hibernate 3 Persistence Unit.</description>
           <jta-data-source>java:jboss/datasources/PlannerDS</jta-data-source>
           <properties>
               <property name="hibernate.show_sql" value="false" />
               <property name="jboss.as.jpa.providerModule" value="hibernate3-bundled" />
           </properties>
       </persistence-unit>
   </persistence>
   
   

   O implantador Java Persistence API (JPA) não irá detectar a presença de um provedor de persistência no aplicativo e uso das bibliotecas Hibernate 3. Conslute a Seção 3.2.2.3, “Propriedades da Unidade de Persistência” para maiores informações sobre as propriedades de persistência JPA.

3. Desativação do cache de segundo nível

   O cache de segundo nível para o Hibernate 3 não exibe o mesmo comportamento com o JBoss EAP 6 assim como fazia nas versões anteriores. Caso você esteja usando o cache de segundo nível com o seu aplicativo, você deve desativá-lo até atualizá-lo para o Hibernate 4. Para desativar o cache de segundo nível, configure o <hibernate.cache.use_second_level_cache> para false no arquivo persistence.xml.

Procedimento 3.14. Atualização do aplicativo para uso do Hibernate 4

1. O comportamento default do gerador do string de incremento automático foi alterado no JBoss EAP 6. Consulte a Seção 3.2.2.5, “Mantenha o Comportamento Existente do Valor Gerado Automaticamente da Identidade Hibernate” para maiores informações.
2. Determine a versão do Hibernate sendo utilizada pelo aplicativo e escolha o procedimento de atualização correto abaixo.
   • Seção 3.2.2.6, “Migração de seu Aplicativo Hibernate 3.3.x para o Hibernate 4.x ”
   • Seção 3.2.2.7, “Migração de seu Aplicativo Hibernate 3.5.x para o Hibernate 4.x”
3. Consulte a Seção 3.2.2.8, “Modificação das Propriedades de Persistência para o Seam Migrado” caso planeje executar seu aplicativo num ambiente com cluster.

1. Mapeie os tipos de text Hibernate para JDBC LONGVARCHAR

   Nas versões anteriores do Hibernate 3.5, o tipo de text era mapeado para JDBC CLOB. Um novo tipo de Hibernate, materialized_clob, foi adicionado ao Hibernate 4 para mapear as propriedades Java String para JDBC CLOB. Caso o seu aplicativo possuir propriedades configuradas como type="text", que possuem por intenção serem mapeadas para JDBC CLOB, o seguinte deve ser realizado:
   1. Caso o seu aplicativo usar arquivos de mapeamento hbm, altere a propriedade para type="materialized_clob".
   2. Caso seu aplicativo usar anotações, você deve substituir @Type(type = "text") por @Lob.

2. Revise o código para encontrar alterações em tipos de valores retornados

   As projeções de critério agregado numérico retornam agora o mesmo tipo de valor de seus counterparts HQL. Como resultado, os tipos de retorno das projeções seguintes no org.hibernate.criterion foram alteradas.
   1. Devido às alterações no CountProjection, Projections.rowCount(), Projections.count(propertyName) e Projections.countDistinct(propertyName), as projeções count e count distinct retornam agora um valor Long.
   2. Devido às alterações no Projections.sum(propertyName), as projeções sum retornam agora um tipo de valor que depende do tipo de propriedade.

      Nota

      Falha ao modificar o seu código do aplicativo num java.lang.ClassCastException.
      1. Para propriedades mapeadas com tipos de número primitivo, Número, Longo ou Curto, o valor Longo é retornado;
      2. Para propriedades mapeadas como tipos de ponto flutuante primitivo, Duplo ou Flutuante, o valor Duplo é retornado.

1. Mescle a configuração da Anotação na Configuração.
   Embora o AnnotationConfiguration tenha sido substituído, ele não deve afetar a sua migração.
   Caso você esteja usando um arquivo hbm.xml, você deve estar ciente que o JBoss EAP 6 usa o org.hibernate.cfg.EJB3NamingStrategy no AnnotationConfiguration ao invés do org.hibernate.cfg.DefaultNamingStrategy que foi usado em versões anteriores. Isto pode resultar em incompatibilidade de nomeação. Caso você baseie-se na estratégia de nomeação para o default do nome de uma tabela associada (muitos-para-muitos e coleções de elementos), você poderá ver esse problema. Para resolver isto, você pode solicitar ao Hibernate a usar o org.hibernate.cfg.DefaultNamingStrategy de legacia chamando o Configuration#setNamingStrategy e passando-o ao org.hibernate.cfg.DefaultNamingStrategy#INSTANCE.
2. Modifique os namespaces para estar de acordo com os novos nomes de arquivos do Hibernate DTD, conforme descrito na tabela abaixo.

   Tabela 3.5. Tabela de Mapeamento do DTD Namespace

   DTD Namespace anterior	Novo DTD Namespace
   http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd	http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd
   http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd	http://www.hibernate.org/dtd/hibernate-mapping-3.0.dtd

3. Modifique as variáveis do ambiente.
   1. Caso você esteja usando o Oracle e usando as propriedades materialized_clob ou materialized_blob, a variável de ambiente global hibernate.jdbc.use_streams_for_binary deve ser configurada para verdadeiro.
   2. Caso você esteja usando o PostgreSQL e usando as propriedades CLOB ou BLOB, o hibernate.jdbc.use_streams_for_binary da variável do ambiente global deve ser configurado para falso.

Procedimento 3.15. Configuração das propriedades a serem executadas num ambiente com cluster

1. Determine o valor hibernate.session_factory_name a um nome único. Este nome deve ser único por todas as implantações de aplicativo na instância do JBoss Enterprise. Por exemplo:

   <property name="hibernate.session_factory_name" value="jboss-seam-booking.ear_session_factory"/>
   
   

2. Determine o valor hibernate.ejb.entitymanager_factory_name a um nome único. Este nome deve ser único para todas as implantações do aplicativo na instância do JBoss EAP 6.

   <property name="hibernate.ejb.entitymanager_factory_name" value="seam-booking.ear_PersistenceUnitName"/>
   
   

Procedimento 3.16. Modificação do arquivo persistence.xml para uso Infinispan

1. Configuração Infinispan para o aplicativo JPA no JBoss EAP 6

   Esta é a forma de como você especifica as propriedades para arquivo de mesma configuração para o aplicativo JPA usando o Infinispan no JBoss EAP 6:

   <property name="hibernate.cache.use_second_level_cache" value="true"/>
   
   

   Além disso, você precisa especificar um shared-cache-mode com um valor de ENABLE_SELECTIVE ou ALL conforme abaixo:
   • O ENABLE_SELECTIVE é o default e valor recomendado. Isto significa que as entidades não possuem cache a não que você marque-as como com cache.

     <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
     
     

   • ALL significa que as entidades sempre possuem cache mesmo que você as marque sem cache.

     <shared-cache-mode>ALL</shared-cache-mode>
     
     

2. Configure o Infinispan para o aplicativo Hibernate native no JBoss EAP 6

   Isto é como você pode especificar a mesma configuração para o aplicativo Hibernate native usando o Infinispan com o JBoss EAP 6:

   <property name="hibernate.cache.region.factory_class"
        value="org.jboss.as.jpa.hibernate4.infinispan.InfinispanRegionFactory"/>
   <property name="hibernate.cache.infinispan.cachemanager"
        value="java:jboss/infinispan/container/hibernate"/>     
   <property name="hibernate.transaction.manager_lookup_class"
        value="org.hibernate.transaction.JBossTransactionManagerLookup"/>
   <property name="hibernate.cache.use_second_level_cache" value="true"/>
   
   
   

   Você deve adicionar a seguinte dependência ao arquivo MANIFEST.MF:

   Manifest-Version: 1.0
   Dependencies: org.infinispan, org.hibernate
   

Procedimento 3.17. Você pode precisar executar uma ou mais dessas tarefas

1. Acesso ao ValidatorFactory default

   O JBoss EAP 6 realiza o bind no ValidatorFactory default para o contexto JNDI sob o nome java:comp/ValidatorFactory.

2. Compreensão do ciclo de vida da validação trigger

   Quando usado em combinação com o Hibernate Core 4, o ciclo de vida baseado na validação é automaticamente habilitado pelo Hibernate Core.
   1. A validação ocorre nas operações INSERT, UPDATE e DELETE de entidade.
   2. É possível a configuração de grupos a serem validados pelo tipo de evento usando as seguintes propriedades:

      • javax.persistence.validation.group.pre-persist,
      • javax.persistence.validation.group.pre-update
      • javax.persistence.validation.group.pre-remove.

      Os valores dessas propriedades são de vírgula separada, nomes de classe inteiramente qualificada dos grupos a serem validados.
      Os grupos de validação são um novo recurso de especificação da Validação Bean. Caso não deseje aproveitar as vantagens desse novo recurso, nenhuma alteração é requerida na migração para o Hibernate Validator 4.
   3. É possível desativar o ciclo de vida baseado na validação pela configuração da propriedade javax.persistence.validation.mode para none. Outros valores válidos para esta propriedade são auto (o default), callback e ddl.

3. Configuração de seu aplicativo para uso da validação

   1. Caso deseje manualmente controlar a validação, é possível criar um Validador em algumas das seguintes maneiras:

      • Crie uma instância Validator a partir do ValidatorFactory usando o método getValidator().
      • Injete as Instâncias do Validador em seu EJB. O bean CDI ou qualquer outro recurso injetável do Java EE.
   2. É possível usar o ValidatorContext retornado pelo ValidatorFactory.usingContext() para personalizar sua instância do Validador. Você pode configurar um MessageInterpolator, TraverableResolver e ConstraintValidatorFactory personalizado usando o API. Essas interfaces são especificadas na especificação do Bean Validation e são novas ao Hibernate Validator 4.

4. Modificação do código para uso de novas restrições do Bean Validation

   As novas restrições de validação de nível Bean solicitam alterações de código quando migrando ao Hibernate Validator 4.
   1. As restrições nos seguintes pacotes para atualização ao Validador Hibernate 4 devem ser usadas:

      • javax.validation.constraints
      • org.hibernate.validator.constraints
   2. Todas as restrições que existiam no Hibernate Validator 3 continuam disponíveis no Hibernate Validator 4. Para usá-las, é necessário importar a classe especificada e em alguns casos alterar o nome ou tipo de parâmetro de restrição.

5. Uso de restrição personalizada

   No Hibernate Validator 3, é necessária uma restrição personalizada para implantar a interface org.hibernate.validator.Validator. No Hibernate Validator 4, é necessário implantar a interface javax.validation.ConstraintValidator. Essa interface contém os mesmos métodos initialize() e isValid() da interface anterior, no entanto, o método de assinatura foi alterado. Além disso, a alteração DDL não é mais suportada no Hibernate Validator 4.

Procedimento 3.18. Criação do JMS Bridge

1. Configuração do Bridge no Servidor do JBoss EAP 5.x de Fonte

   Para evitar conflitos nas classes entre os lançamentos, você deve seguir essas etapas para configurar o JMS bridge no JBoss EAP 5.x. Os nomes do diretório SAR e o bridge são arbitrários e podem ser alterados se você preferir.
   1. Crie um diretório de implementação do JBoss EAP 5 para conter o SAR, por exemplo: EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/.
   2. Crie um subdiretório nomeado META-INF no EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/.
   3. Crie um arquivo jboss-service.xml no diretório EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/META-INF/. Ele deve conter informação similar à seguinte amostra.

      <server>
         <loader-repository>
            com.example:archive=unique-archive-name
            <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
         </loader-repository> 
      
         <!-- JBoss EAP 6 JMS Provider --> 
         <mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.messaging:service=JMSProviderLoader,name=EnterpriseApplicationPlatform6JMSProvider">
            <attribute name="ProviderName">EnterpriseApplicationPlatform6JMSProvider</attribute>
            <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
            <attribute name="FactoryRef">jms/RemoteConnectionFactory</attribute> 
            <attribute name="QueueFactoryRef">jms/RemoteConnectionFactory</attribute>  
            <attribute name="TopicFactoryRef">jms/RemoteConnectionFactory</attribute>      
            <attribute name="Properties">
               java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
               java.naming.provider.url=remote://EnterpriseApplicationPlatform6host:4447
               java.naming.security.principal=jbossuser
               java.naming.security.credentials=jbosspass
            </attribute>
         </mbean> 
      
         <mbean code="org.jboss.jms.server.bridge.BridgeService" name="jboss.jms:service=Bridge,name=MyBridgeName" xmbean-dd="xmdesc/Bridge-xmbean.xml">      
            <depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>          
            <depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=EnterpriseApplicationPlatform6JMSProvider</depends>          
            <attribute name="SourceDestinationLookup">/queue/A</attribute>      
            <attribute name="TargetDestinationLookup">jms/queue/test</attribute>       
            <attribute name="QualityOfServiceMode">1</attribute>           
            <attribute name="MaxBatchSize">1</attribute>      
            <attribute name="MaxBatchTime">-1</attribute>           
            <attribute name="FailureRetryInterval">60000</attribute>      
            <attribute name="MaxRetries">-1</attribute>      
            <attribute name="AddMessageIDInHeader">false</attribute>
            <attribute name="TargetUsername">jbossuser</attribute>
            <attribute name="TargetPassword">jbosspass</attribute>
         </mbean>
      </server>
              
      
      

      Nota

      O elemento load-repository está presente para garantir que o SAR possui um classloader isolado. Além disso, perceba que ambos bridge "destino" e busca JNDI incluem as credenciais para o usuário "jbossuser" com a senha "jbosspass". Isto é devido ao JBoss EAP 6 ser segurado por default. O usuário nomeado "jbossuser" com a senha "jbosspass" foi criado no ApplicationRealm com a função guest usando o script EAP_HOME/bin/add_user.sh.
   4. Copie os seguintes JARs a partir do diretório EAP_HOME/modules/system/layers/base/ no diretório EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/. Substitua cada VERSION_NUMBER pelo número de versão em sua distribuição do JBoss EAP 6.

      • org/hornetq/main/hornetq-core-VERSION_NUMBER.jar
      • org/hornetq/main/hornetq-jms-VERSION_NUMBER.jar
      • org/jboss/ejb-client/main/jboss-ejb-client-VERSION_NUMBER.jar
      • org/jboss/logging/main/jboss-logging-VERSION_NUMBER.jar
      • org/jboss/logmanager/main/jboss-logmanager-VERSION_NUMBER.jar
      • org/jboss/marshalling/main/jboss-marshalling-VERSION_NUMBER.jar
      • org/jboss/marshalling/river/main/jboss-marshalling-river-VERSION_NUMBER.jar
      • org/jboss/remote-naming/main/jboss-remote-naming-VERSION_NUMBER.jar
      • org/jboss/remoting3/main/jboss-remoting-VERSION_NUMBER.jar
      • org/jboss/sasl/main/jboss-sasl-VERSION_NUMBER.jar
      • org/jboss/netty/main/netty-VERSION_NUMBER.jar
      • org/jboss/remoting3/remote-jmx/main/remoting-jmx-VERSION_NUMBER.jar
      • org/jboss/xnio/main/xnio-api-VERSION_NUMBER.jar
      • org/jboss/xnio/nio/main.xnio-nio-VERSION_NUMBER.jar

      Nota

      Não copie simplesmente o EAP_HOME/bin/client/jboss-client.jar uma vez que as classes javax API classes entrarão em conflito com aquelas do JBoss EAP 5.x.

2. Configuração do Bridge no Servidor do JBoss EAP 6 de Destinação

   No JBoss EAP 6.1 e versões mais recentes, o JMS bridge pode ser usado para realizar o bridge nas mensagens a partir de qualquer servidor compatível com o JMS 1.1. Uma vez que os recursos JMS de destino e fonte são pesquisados usando o JNDI, as classes de busca JNDI do provedor de mensagem fonte, ou agente da mensagem, devem ser empacotadas num Módulo do JBoss. As seguintes etapas usam o agente de mensagem 'MyCustomMQ' como um exemplo.
   1. Criação do módulo do JBoss para o provedor de mensagem.
      1. Crie uma estrutura de diretório sob o EAP_HOME/modules/system/layers/base/ para o novo módulo. O subdiretório main/ conterá o cliente JARs e o arquivo module.xml. Segue abaixo uma amostra da estrutura do diretório criada para o provedor de mensagem MyCustomMQ: EAP_HOME/modules/system/layers/base/org/mycustommq/main/
      2. No subdiretório main/, crie um arquivo module.xml contendo a definição do módulo para o provedor de mensagem. Segue abaixo uma amostra do module.xml criado para o provedor de mensagem MyCustomMQ.

         <?xml version="1.0" encoding="UTF-8"?>
         <module xmlns="urn:jboss:module:1.1" name="org.mycustommq">
             <properties>
                 <property name="jboss.api" value="private"/>
             </properties> 
         
             <resources>
                 <!-- Insert resources required to connect to the source or target   -->
                 <resource-root path="mycustommq-1.2.3.jar" />
                 <resource-root path="mylogapi-0.0.1.jar" />
             </resources> 
         
             <dependencies>
                <!-- Add the dependencies required by JMS Bridge code                 -->
                <module name="javax.api" />
                <module name="javax.jms.api" />
                <module name="javax.transaction.api"/>
                <!-- Add a dependency on the org.hornetq module since we send         -->
                <!-- messages tothe HornetQ server embedded in the local EAP instance -->
                <module name="org.hornetq" />
             </dependencies>
         </module>
         
         

      3. Copie a mensagem dos JARs do provedor de mensagem solicitado para a busca JNDI dos recursos de fonte ao subdiretório main/. A estrutura do diretório para o módulo MyCustomMQ deve agora parecer-se com o seguinte.

         modules/
         `-- system
             `-- layers
                 `-- base
                     `-- org
                           `-- mycustommq
                               `-- main
                                   |-- mycustommq-1.2.3.jar
                                   |-- mylogapi-0.0.1.jar
                                   |-- module.xml
         

   2. Configure o JMS bridge no subsistema messaging do servidor do JBoss EAP 6.
      1. Antes de começar, interrompa o servidor e realize o backup dos arquivos de configuração do servidor atual. Caso você esteja executando o servidor autônomo, este é o arquivo EAP_HOME/standalone/configuration/standalone-full-ha.xml. Caso você esteja executando o managed domain, realize o backup em ambos os arquivos EAP_HOME/domain/configuration/domain.xml e EAP_HOME/domain/configuration/host.xml.
      2. Adicione o elemento jms-bridge ao subsistema messaging no arquivo de configuração do servidor. Os elementos source e target fornecem os nomes dos recursos JMS usados para as buscas JNDI. Caso os credenciais user e password forem especificados, eles serão passados como argumentos quando a conexão JMS for criada.
         Segue abaixo uma amostra do elemento jms-bridge configurado para o provedor de mensagem MyCustomMQ:

         <subsystem xmlns="urn:jboss:domain:messaging:1.3">
            ...
            <jms-bridge name="myBridge" module="org.mycustommq">
               <source>
                  <connection-factory name="ConnectionFactory"/>
                  <destination name="sourceQ"/>
                  <user>user1</user>
                  <password>pwd1</password>
                  <context>
                     <property key="java.naming.factory.initial" value="org.mycustommq.jndi.MyCustomMQInitialContextFactory"/>
                     <property key="java.naming.provider.url"    value="tcp://127.0.0.1:9292"/>
                  </context>
               </source>
               <target>
                  <connection-factory name="java:/ConnectionFactory"/>
                  <destination name="/jms/targetQ"/>
               </target>
               <quality-of-service>DUPLICATES_OK</quality-of-service>
               <failure-retry-interval>500</failure-retry-interval>
               <max-retries>1</max-retries>
               <max-batch-size>500</max-batch-size>
               <max-batch-time>500</max-batch-time>
               <add-messageID-in-header>true</add-messageID-in-header>
            </jms-bridge>
         </subsystem>
         
         

         Na amostra acima, as propriedades são definidas no elemento context para o source. Caso o elemento context for omitido como na amostra target acima, os recursos JMS são bloqueados numa instância local.

Procedimento 3.19. Antes de começar

1. Encerre o cliente e o servidor
2. Realize uma cópia do backup de quaisquer dados do JBoss Messaging. Os dados da mensagem são stored num banco de dados com tabelas pré-fixadas com o JBM_.

Procedimento 3.20. Alteração de seu provedor para o HornetQ

1. Configurações de transferências

   Transfira as configurações do JBoss Messaging à configuração do JBoss EAP 6. As seguintes configurações podem ser encontradas nos descritores de implantação localizados no servidor do JBoss Messaging:
   • Configuração do Serviço de Criações da Conexões
     Esta configuração descreve as criações da conexão JMS implantada com o servidor do JBoss Messaging. O JBoss Messaging configura as criações da conexão num arquivo nomeado connection-factories-service.xml, que está localizado no diretório de implantação do servidor do aplicativo.
   • Configuração de Destinação
     Esta configuração descreve as filas JMS e tópicos implantados com o servidor do JBoss Messaging. Por default, o JBoss Messaging configura as destinações num arquivo nomeado destinations-service.xml que está localizado no diretório de implantação no servidor do aplicativo.
   • Configuração do Serviço Bridge de Mensagem
     Esta configuração inclui os serviços bridge implantados com o servidor do JBoss Messaging. Nenhum dos bridges são implantados por default, de forma que o nome do arquivo da implantação varia, dependendo de sua instalação.

2. Modificação de seu código de arquivo

   Caso o código do aplicativo usar o JMS default, nenhuma alteração do código será solicitada. No entanto, caso o aplicativo seja conectado a um cluster, você deverá revisar com cuidado a documentação HornetQ das semânticas de clustering. O clustering está fora do escopo da especificação JMS e o HornetQ e o JBoss Messaging tomaram abordagens diferentes em suas respectivas implementações de funcionalidade de clustering.
   Caso o aplicativo usar recursos específicos do JBoss Messaging, você deverá modificar o código para uso dos recursos equivalentes disponíveis no HornetQ.
   Para maiores informações sobre a configuração do messaging com o HornetQ, consulte a Seção 3.2.7.5, “Configuração de Mensagens com HornetQ”.

3. Migração de mensagens existentes

   Mova quaisquer mensagens do banco de dados do JBoss Messaging ao diário HornetQ usando o JMS bridge. As instruções para configuração do JMS bridge podem ser encontradas na Seção 3.2.7.2, “Configuração do JMS Bridge para Migração de JMS Messages Existentes ao JBoss EAP 6”.

1. Inicie o JBoss EAP 6 com o clustering habilitado

   Para habilitar o clustering no JBoss EAP 5.x, era necessário iniciar suas instâncias do servidor usando o perfil all ou alguma derivação do mesmo, como por exemplo:

   $ EAP5_HOME/bin/run.sh -c all

   No JBoss EAP 6, o método para a habilitação do clustering depende dos servidores serem autônomos ou serem executados num managed domain.

   1. Habilitação do cluster para servidores executando num managed domain

      Para habilitar o clustering para servidores iniciados usando o domain controller, atualize o seu domain.xml e determine um grupo de servidor para uso do seu perfil ha e grupo socket binding ha-sockets. Por exemplo:

      <server-groups>
        <server-group name="main-server-group" profile="ha">
          <jvm name="default">
            <heap size="64m" max-size="512m"/>
          </jvm>
          <socket-binding-group ref="ha-sockets"/>
        </server-group>
      </server-group>
      

   2. Habilitação do cluster para servidores autônomos

      Inicie o servidor usando o arquivo de configuração apropriado conforme a seguinte amostra de habilitação do cluster para servidores autônomos:

      $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME

2. Especificação do endereço bind

   No JBoss EAP 5.x, você normalmente indica o endereço bind usado para clustering usando o argumento da linha de comando -b, conforme abaixo:

   $ EAP5_HOME/bin/run.sh -c all -b 192.168.0.2

   OJBoss EAP 6 realiza o bind sockets nos endereços IP e interfaces contidas nos elementos <interfaces> dos arquivos standalone.xml, domain.xml e host.xml. As configurações padrões que lançam o JBoss EAP incluem duas configurações de interface:

   <interfaces>
       <interface name="management">
           <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
       </interface>
       <interface name="public">
          <inet-address value="${jboss.bind.address:127.0.0.1}"/>
       </interface>
   </interfaces>
   

   Essas configurações de interface usam valores do jboss.bind.address.management e jboss.bind.address de propriedades de sistema. Caso as propriedades de sistema não sejam determinadas, o default 127.0.0.1 é usado para cada valor.
   O endereço bind pode ser definido como um argumento da linha de comando quando você inicia o servidor ou você pode explicitamente defini-lo com o arquivo de configuração do servidor do JBoss EAP 6.
   • Especifique o argumento bind na linha de comando quando iniciando o servidor autônomo do JBoss EAP.
     Segue abaixo uma amostra de como especificar o endereço bind na linha de comando para o servidor autônomo:

     EAP_HOME/bin/standalone.sh -Djboss.bind.address=127.0.0.1

     Nota

     É possível usar o argumento -b, que é um atalho para o -Djboss.bind.address=127.0.0.1:

     EAP_HOME/bin/standalone.sh -b=127.0.0.1

     O formato de sintaxe JBoss EAP 5 também é suportado:

     EAP_HOME/bin/standalone.sh -b 127.0.0.1

     Perceba que o argumento -b apenas modifica as alterações da interface public. Isto não afeta a interface management.
   • Especifique o endereço bind no arquivo de configuração do servidor.
     Especifique os endereços bind no arquivo domain/configuration/host.xml para servidores executando num managed domain. Para servidores autônomos, especifique os endereços bind no arquivo standalone-ha.xml.
     A interface public na seguinte amostra é especificada como interface default para todos os sockets do grupo socket binding ha-sockets.

     <interfaces>
       <interface name="management">
         <inet-address value="192.168.0.2"/>
       </interface>
       <interface name="public">
         <inet-address value="192.168.0.2"/>
       </interface>
     </interfaces>
     

     <socket-binding-groups>
       <socket-binding-group name="ha-sockets" default-interface="public">
         <!-- ... -->
       </socket-binding-group>
     </socket-binding-groups>
     

     Nota

     Caso o endereço bind for especificado como um valor codificado ao invés de uma propriedade de sistema no arquivo de configuração, não será possível substituí-lo num argumento da linha de comando.

3. Configure o jvmRoute para suportar o mod_jk e mod_proxy

   No JBoss EAP 5, o servidor da web jvmRoute foi configurado usando a propriedade no arquivo server.xml. No JBoss EAP 6, o atributo jvmRoute é configurado no subsistema da web do arquivo de combinação do servidor usando o atributo instance-id, conforme o seguinte:

   <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false" instance-id="{JVM_ROUTE_SERVER}">
   
   

   O {JVM_ROUTE_SERVER} acima deve ser substituído pela ID do servidor jvmRoute.
   O instance-id pode ser determinado usando o Management Console.

4. Especificação do endereço multicast e porta

   No JBoss EAP 5.x, é possível especificar a porta e o endereço multicast usados para a comunicação de intra-cluste usando os argumentos -u e -m da linha de comando, conforme abaixo:

   $ EAP5_HOME/bin/run.sh -c all -u 228.11.11.11 -m 45688

   No JBoss EAP 6, o endereço e porta multicast usados para a comunicação do cluster são definidos pelo socket-binding referenciado pela pilha do protocolo JGroups relevante, conforme abaixo:

   <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
       <stack name="udp">
           <transport type="UDP" socket-binding="jgroups-udp"/>
           <!-- ... -->
       </stack>
   </subsystem>
   

   <socket-binding-groups>
       <socket-binding-group name="ha-sockets" default-interface="public">
           <!-- ... -->
           <socket-binding name="jgroups-udp" port="55200" multicast-address="228.11.11.11" multicast-port="45688"/>
           <!-- ... -->
       </socket-binding-group>
   </socket-binding-groups>
   
   

   Caso você preferir especificar o endereço multicast e a porta na linha de comando, você pode definir o endereço multicast e as portas como propriedades de sistema e usá-las na linha de comando quando você iniciar o servidor. A seguinte amostra, jboss.mcast.addr é o nome da variável para o endereço multicast e o jboss.mcast.port é o nome da variável para a porta.

   <socket-binding name="jgroups-udp" port="55200"
    multicast-address="${jboss.mcast.addr:230.0.0.4}" multicast-port="${jboss.mcast.port:45688}"/>
   
   

   Você pode iniciar o seu servidor usando os seguintes argumentos da linha de comando:

   $ EAP_HOME/bin/domain.sh -Djboss.mcast.addr=228.11.11.11 -Djboss.mcast.port=45688

5. Uso da pilha de protocolo alternativo

   No JBoss EAP 5.x, é possível manipular a pilha do protocolo default para todos os serviços de clustering usando a propriedade de sistema jboss.default.jgroups.stack.

   $ EAP5_HOME/bin/run.sh -c all -Djboss.default.jgroups.stack=tcp

   No JBoss EAP 6, a pilha do protocolo default é definida pelo subsistema JGroups com o domain.xml ou standalone-ha.xml:

   <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
       <stack name="udp">
           <!-- ... -->
       </stack>
   </subsystem>
   

6. Substituição da Replicação Buddy

   O JBoss EAP 5.x usava o JBoss Cache Buddy Replication para suprimir a replicação de dados de todas as instâncias num cluster.
   No JBoss EAP 6, o Buddy Replication foi substituído pelo cache distribuído do Infinispan, também conhecido como modo DIST. A distribuição é um modo de clustering que permite o Infinispan escalar linearmente com mais servidores que são adicionados ao cluster. Segue abaixo uma amostra de como configurar o servidor para uso no modo de DIST caching.
   1. Abra a linha de comando e inicie o servidor com tanto o Perfil Completo ou HA. Por exemplo:

      EAP_HOME/bin/standalone.sh -c standalone-ha.xml

   2. Abra outra linha de comando e conecte-se ao Management CLI.
      • Insira a seguinte linha de comando para o Linux:

        $ EAP_HOME/bin/jboss-cli.sh --connect
        

      • Insira a seguinte linha de comando para o Windows:

        C:\>EAP_HOME\bin\jboss-cli.bat --connect
        

      Você deverá observar a seguinte resposta:

      Conectado ao controlador autônomo no localhost:9999

   3. Adicione os seguintes comandos:

      /subsystem=infinispan/cache-container=web/:write-attribute(name=default-cache,value=dist)
      /subsystem=infinispan/cache-container=web/distributed-cache=dist/:write-attribute(name=owners,value=3)
      :reload
      

      Você deverá ver a seguinte resposta após cada comando:

      "outcome" => "success"
      

      Esses comandos modificam o elemento dist <distributed-cache> na configuração web <cache-container> do subsistema infinispan do arquivo standalone-ha.xml, conforme abaixo:

      <cache-container name="web" aliases="standard-session-cache" default-cache="dist" module="org.jboss.as.clustering.web.infinispan">
          <transport lock-timeout="60000"/>
          <replicated-cache name="repl" mode="ASYNC" batching="true">
              <file-store/>
          </replicated-cache>
          <replicated-cache name="sso" mode="SYNC" batching="true"/>
          <distributed-cache name="dist" owners="3" l1-lifespan="0" mode="ASYNC" batching="true">
              <file-store/>
          </distributed-cache>
      </cache-container>
      
      

      Refira-se ao capítulo nomeado Clustering nos Aplicativos da Web no Guia de Desenvolvimento do JBoss EAP 6 localizado no Portal do Cliente https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ para maiores informações a este respeito.

Procedimento 3.21. Implantação do Serviço HA Singleton

1. Grave o aplicativo do serviço HA singleton.

   Segue abaixo uma amostra de um Service que está encapsulado como decorador SingletonService a ser implantado como um serviço singleton. Uma amostra completa pode ser encontrada na iniciação rápida cluster-ha-singleton que lança o Red Hat JBoss Enterprise Application Platform 6. Esta iniciação rápida contém todas as instruções de construção e implantação do aplicativo.

   1. Criação de um serviço.

      A lista abaixo é uma amostra de um serviço:

      package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
      
      import java.util.Date;
      import java.util.concurrent.atomic.AtomicBoolean;
      
      import javax.naming.InitialContext;
      import javax.naming.NamingException;
      
      import org.jboss.logging.Logger;
      import org.jboss.msc.service.Service;
      import org.jboss.msc.service.ServiceName;
      import org.jboss.msc.service.StartContext;
      import org.jboss.msc.service.StartException;
      import org.jboss.msc.service.StopContext;
      
      
      /**
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      public class HATimerService implements Service<String> {
          private static final Logger LOGGER = Logger.getLogger(HATimerService.class);
          public static final ServiceName SINGLETON_SERVICE_NAME = ServiceName.JBOSS.append("quickstart", "ha", "singleton", "timer");
      
          /**
           * A flag whether the service is started.
           */
          private final AtomicBoolean started = new AtomicBoolean(false);
      
          /**
           * @return the name of the server node
           */
          public String getValue() throws IllegalStateException, IllegalArgumentException {
              LOGGER.infof("%s is %s at %s", HATimerService.class.getSimpleName(), (started.get() ? "started" : "not started"), System.getProperty("jboss.node.name"));
              return "";
          }
      
          public void start(StartContext arg0) throws StartException {
              if (!started.compareAndSet(false, true)) {
                  throw new StartException("The service is still started!");
              }
              LOGGER.info("Start HASingleton timer service '" + this.getClass().getName() + "'");
      
              final String node = System.getProperty("jboss.node.name");
              try {
                  InitialContext ic = new InitialContext();
                  ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).initialize("HASingleton timer @" + node + " " + new Date());
              } catch (NamingException e) {
                  throw new StartException("Could not initialize timer", e);
              }
          }
      
          public void stop(StopContext arg0) {
              if (!started.compareAndSet(true, false)) {
                  LOGGER.warn("The service '" + this.getClass().getName() + "' is not active!");
              } else {
                  LOGGER.info("Stop HASingleton timer service '" + this.getClass().getName() + "'");
                  try {
                      InitialContext ic = new InitialContext();
                      ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).stop();
                  } catch (NamingException e) {
                      LOGGER.error("Could not stop timer", e);
                  }
              }
          }
      }
      
      

   2. Crie um ativador que instala o Service como um clustered singleton com cluster.

      Segue abaixo uma lista de amostra do ativador de Serviço que instala o HATimerService como um serviço singleton com cluster:

      package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
      
      import org.jboss.as.clustering.singleton.SingletonService;
      import org.jboss.logging.Logger;
      import org.jboss.msc.service.DelegatingServiceContainer;
      import org.jboss.msc.service.ServiceActivator;
      import org.jboss.msc.service.ServiceActivatorContext;
      import org.jboss.msc.service.ServiceController;
      
      
      /**
       * Service activator that installs the HATimerService as a clustered singleton service
       * during deployment.
       *
       * @author Paul Ferraro
       */
      public class HATimerServiceActivator implements ServiceActivator {
          private final Logger log = Logger.getLogger(this.getClass());
      
          @Override
          public void activate(ServiceActivatorContext context) {
              log.info("HATimerService will be installed!");
      
              HATimerService service = new HATimerService();
              SingletonService<String> singleton = new SingletonService<String>(service, HATimerService.SINGLETON_SERVICE_NAME);
              /*
               * To pass a chain of election policies to the singleton, for example, 
               * to tell JGroups to prefer running the singleton on a node with a
               * particular name, uncomment the following line:
               */
              // singleton.setElectionPolicy(new PreferredSingletonElectionPolicy(new SimpleSingletonElectionPolicy(), new NamePreference("node2/cluster")));
      
              singleton.build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry()))
                      .setInitialMode(ServiceController.Mode.ACTIVE)
                      .install()
              ;
          }
      }
      
      

      Nota

      A amostra de código acima usa a classe,org.jboss.as.clustering.singleton.SingletonService, que faz parte do JBoss EAP private API. Um API irá tornar-se disponível no lançamento EAP 7 e a classe privada será preterida, porém estas classes serão mantidas e disponíveis pela duração do ciclo de lançamento do EAP 6.x.

   3. Crie um Arquivo ServiceActivator

      Crie um arquivo nomeado org.jboss.msc.service.ServiceActivator no diretório do arquivo resources/META-INF/services/. Adicione uma linha contendo um nome inteiramente qualificado da classe do ServiceActivator criada na etapa anterior.

      org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator 

   4. Crie um Singleton bean que implementa um timer usado como um timer singleton amplo com cluster.

      Este Singleton bean não deve possuir uma interface remota e a interface local não deve ser referenciada por outro EJB em qualquer aplicativo. Isto previne uma busca pelo cliente ou outro componente e garante que o SingletonService possua controle total do Singleton.

      1. Crie um interface do Esquematizador

         package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
         
         /**
          * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
          */
         public interface Scheduler {
         
             void initialize(String info);
         
             void stop();
         
         } 
         
         

      2. Crie um bean do Singleton que implementa o timer do singleton amplo com cluster.

         package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
         
         import javax.annotation.Resource;
         import javax.ejb.ScheduleExpression;
         import javax.ejb.Singleton;
         import javax.ejb.Timeout;
         import javax.ejb.Timer;
         import javax.ejb.TimerConfig;
         import javax.ejb.TimerService;
         
         import org.jboss.logging.Logger;
         
         
         /**
          * A simple example to demonstrate a implementation of a cluster-wide singleton timer.
          *
          * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
          */
         @Singleton
         public class SchedulerBean implements Scheduler {
             private static Logger LOGGER = Logger.getLogger(SchedulerBean.class);
             @Resource
             private TimerService timerService;
         
             @Timeout
             public void scheduler(Timer timer) {
                 LOGGER.info("HASingletonTimer: Info=" + timer.getInfo());
             }
         
             @Override
             public void initialize(String info) {
                 ScheduleExpression sexpr = new ScheduleExpression();
                 // set schedule to every 10 seconds for demonstration
                 sexpr.hour("*").minute("*").second("0/10");
                 // persistent must be false because the timer is started by the HASingleton service
                 timerService.createCalendarTimer(sexpr, new TimerConfig(info, false));
             }
         
             @Override
             public void stop() {
                 LOGGER.info("Stop all existing HASingleton timers");
                 for (Timer timer : timerService.getTimers()) {
                     LOGGER.trace("Stop HASingleton timer: " + timer.getInfo());
                     timer.cancel();
                 }
             }
         }
         
         

2. Inicie cada instância do JBoss EAP 6 com o clustering habilitado.

   Você deve iniciar cada servidor com o perfil HA, usando um nome de nó único e uma porta de deslocamento para cada instância.
   • No Linux, use a seguinte sintaxe de comando para iniciar os servidores:

     EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME -Djboss.socket.binding.port-offset=PORT_OFFSET

     Exemplo 3.1. Inicie os servidores autônomos no Linux

     $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node1
     $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100

   • No Microsoft Windows, use a seguinte sintaxe de comando para iniciar os servidores:

     EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME -Djboss.socket.binding.port-offset=PORT_OFFSET

     Exemplo 3.2. Inicie os servidores autônomos no Microsoft Windows

     C:> EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=node1
     C:> EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100

   Nota

   Caso decida por não usar os argumentos da linha de comando, o arquivo standalone-ha.xml pode ser configurado para cada instância para efetuar o bind numa interface separada.

3. Implantação do aplicativo aos servidores

   O seguinte comando Maven implanta o aplicativo a um servidor executando em portas default.

   mvn clean install jboss-as:deploy

   Para implantação de servidores adicionais, passe o nome do servidor. Caso esteja em um host diferente, passe o nome do host e o número da porta na linha de comando:

   mvn clean package jboss-as:deploy -Djboss-as.hostname=localhost -Djboss-as.port=10099

   Consulte a iniciação rápida cluster-ha-singleton que lança o JBoss EAP 6 para maiores detalhes da configuração e implantação Maven .

Procedimento 3.22. Adição da Configuração do Projeto Maven para a Invocação Remota dos Beans de Sessão

1. Adicione as dependências do projeto solicitadas

   O pom.xml para o projeto deve ser atualizado para incluir as dependências necessárias.

2. Adicione o arquivo jboss-ejb-client.properties

   O API do cliente JBoss EJB espera encontrar um arquivo na raiz do projeto nomeado jboss-ejb-client.properties que contém a informação da conexão para o serviço JNDI. Adicione este arquivo ao diretório src/main/resources/ de seu projeto com o seguinte conteúdo.

   # In the following line, set SSL_ENABLED to true for SSL
   remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
   remote.connections=default
   # Uncomment the following line to set SSL_STARTTLS to true for SSL
   # remote.connection.default.connect.options.org.xnio.Options.SSL_STARTTLS=true
   remote.connection.default.host=localhost
   remote.connection.default.port = 4447
   remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
   # Add any of the following SASL options if required
   # remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
   # remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
   # remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
   
   

   Altere o portal e o nome do host para coincidir com o seu servidor. O 4447 é o número de porta default. Configure a linha SSL_ENABLED para true e descomente a linha SSL_STARTTLS. A interface remota no contêiner suporta as conexões com e sem segurança usando a mesma porta.

3. Adicione dependências para as interfaces comerciais

   Adicione as dependências Maven ao pom.xml para interfaces comerciais remotas dos beans de sessão.

   <dependency>
      <groupId>org.jboss.as.quickstarts</groupId>
      <artifactId>jboss-ejb-remote-server-side</artifactId>
      <type>ejb-client</type>
      <version>${project.version}</version>
   </dependency>
   

Procedimento 3.23. Obtenção de um Proxy Bean usando o JNDI e Métodos de Invocação do Bean

1. Manuseio das exceções checadas

   Os métodos usados no seguinte código (InitialContext() e lookup()) possuem uma exceção de checagem do tipo javax.naming.NamingException. Essas chamadas de método devem tanto ser inseridas num bloco de tentativa/captura que captura o NamingException ou num método que é declarado ao lançar o NamingException. A iniciação rápida do ejb-remote usa a segunda técnica.

2. Criação do Contexto JNDI

   O objetivo do Contexto JNDI fornece o mecanismo de solicitação de recursos a partir do servidor. Crie um contexto JNDI usando o seguinte código:

   final Hashtable jndiProperties = new Hashtable();
   jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
   final Context context = new InitialContext(jndiProperties);
   

   As propriedades de conexão para o serviço JNDI são lidas a partir do arquivo jboss-ejb-client.properties.

3. Uso do método lookup() do Contextp JNDI para obter um proxy de bean

   Invoque o método lookup() do proxy do bean e passe-o ao nome JNDI do bean de sessão que você requer. Isto retornará um objeto que deve ser convertido ao tipo de interface comercial remota que contém os métodos que você deseje invocar.

   
   final RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
       "ejb:/jboss-ejb-remote-server-side//CalculatorBean!" + 
       RemoteCalculator.class.getName());
   
   

   Os nomes JNDI do bean de sessão são definidos usando uma sintaxe especial. Consulte a Seção 3.2.10.3, “Referência de Nomeação EJB JNDI ” para maiores informações.

4. Métodos de Invocação

   Agora que você possui um objeto de bean de proxy, é possível invocar qualquer um dos métodos contidos na interface comercial remota.

   int a = 204;
   int b = 340;
   System.out.println("Adding " + a + " and " + b + " via the remote stateless calculator deployed on the server");
   int sum = statelessRemoteCalculator.add(a, b);
   System.out.println("Remote calculator returned sum = " + sum);
   

   O bean passa a solicitação de invocação do método ao bean de sessão no servidor, onde isto é executado. O resultado é retornado ao bean do proxy que então o retorna ao chamador. A comunicação entre o bean de proxy e o bean de sessão remota é transparente ao chamador.

Procedimento 3.25. Migração dos Arquivos Seam 2.2

1. Atualização da configuração da fonte de dados

   Algumas das amostras Seam 2.2 usam a fonte de dados JDBC default nomeada java:/ExampleDS. A fonte de dados default foi alterada no JBoss EAP 6 para java:jboss/datasources/ExampleDS. Caso seu aplicativo usar a fonte de dados da amostra, você pode realizar o seguinte:

   • Caso você deseje usar um banco de dados de amostra que lança o JBoss EAP 6, modifique o arquivo META-INF/persistence.xml para substituir o elemento jta-data-source existente com o nome JNDI da fonte de dados do banco de dados de amostra:

     <!-- <jta-data-source>java:/ExampleDS</jta-data-source> -->
     <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
     

   • Caso você preferir manter um banco de dados existente, você pode adicionar a definição da fonte de dados ao arquivo EAP_HOME/standalone/configuration/standalone.xml.

     Importante

     Você deve interromper o servidor antes de editar o arquivo de configuração do servidor para que sua alteração seja efetivada no reinício do servidor.
     A seguinte definição é uma cópia da fonte de dados HSQL definida no JBoss EAP 6:

     <datasource name="ExampleDS" jndi-name="java:/ExampleDS" enabled="true" jta="true" use-java-context="true" use-ccm="true">
        <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
        <security>
           <user-name>sa</user-name>
           <password>sa</password>
        </security>
     </datasource>
     

   • Você pode também adicionar a definição da fonte de dados usando a interface da linha de comando do Management CLI. Segue abaixo uma amostra da sintaxe que você deve usar para adicionar a fonte de dados. O "\" no final da linha indica a continuação do comando na linha seguinte.

     Exemplo 3.3. Amostra da sintaxe para adição da definição da fonte de dados

     $ EAP_HOME/bin/jboss-cli --connect 
     [standalone@localhost:9999 /] data-source add --name=ExampleDS --jndi-name=java:/ExampleDS \ 
           --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --driver-name=h2 \ 
           --user-name=sa --password=sa
     

   Consulte a Seção 3.1.6.2, “Atualização da Configuração da Fonte de Dados” para maiores informações de como configurar a fonte de dados.

2. Adição de quaisquer dependências requeridas

   Uma vez que os aplicativos Seam 2.2 usam o JSF 1.2, você precisa adicionar dependências para os módulos JSF 1.2 e excluir os módulos JSF 2.0. Para completar este procedimento, você precisa criar um arquivo jboss-deployment-structure.xml no diretório META-INF/ do EAR que contém os seguintes dados:

   <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
     <deployment>
         <dependencies>
           <module name="javax.faces.api" slot="1.2" export="true"/>
                 <module name="com.sun.jsf-impl" slot="1.2" export="true"/>
         </dependencies>
     </deployment>
     <sub-deployment name="jboss-seam-booking.war">
       <exclusions>
           <module name="javax.faces.api" slot="main"/>
                 <module name="com.sun.jsf-impl" slot="main"/>
         </exclusions>
         <dependencies>
           <module name="javax.faces.api" slot="1.2"/>
                 <module name="com.sun.jsf-impl" slot="1.2"/>
         </dependencies>
     </sub-deployment>
   </jboss-deployment-structure>
   

   Caso seu aplicativo usar frameworks de registro em log de terceiros, você precisa adicionar as dependências descritas na: Seção 3.1.4.1, “Modificação das Dependências de Registro em Log”.

3. Caso o seu aplicativo usar o Hibernate 3.x, primeiro tente executar o aplicativo usando as bibliotecas do Hibernate 4

   Caso o seu aplicativo não usar o Contexto Persistente Gerenciado Seam, busca Hibernate, validação ou quaisquer outros recursos com o Hibernate 4, você pode estar apto a executar com as bibliotecas do Hibernate 4. No entanto, caso você observar o ClassNotFoundExceptions ou ClassCastExceptions que direcionam às classes Hibernate ou verificar erros similares aos seguintes, você terá que seguir as instruções da próxima etapa e modificar o seu aplicativo para uso das bibliotecas do Hibernate 3.3.

           Caused by: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.jboss.seam.persistence.HibernateSessionProxy.getSession(Lorg/hibernate/EntityMode;)Lorg/hibernate/Session;" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, org/jboss/seam/persistence/HibernateSessionProxy, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for interface org/hibernate/Session have different Class objects for the type org/hibernate/Session used in the signature
   

4. Cópia dos arquivos dependentes a partir dos frameworks externos ou de outras localizações

   Caso o seu aplicativo usar o Hibernate 3.x e você não estiver apto a usar o Hibernate 4 com sucesso no seu aplicativo, você precisará usar uma cópia do Hibernate 3-x JARs no diretório /lib e excluir o módulo Hibernate na seção de implantações do META-INF/jboss-deployment-structure.xml, conforme o seguinte:

   <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
    <deployment>
      <exclusions>
        <module name="org.hibernate"/>
      </exclusions>
    <deployment>
   </jboss-deployment-structure>
   

   Não existe nenhuma etapa adicional que você deve realizar quando você aplicar o bundle no seu aplicativo. Consulte a Seção 3.2.2.2, “Configuração das Alterações para Aplicativos que usam o Hibernate e o JPA” para maiores informações.

5. Depuração e resolução dos erros Seam 2.2 JNDI

   Quando você migrar o aplicativo Seam 2.2, você poderá ver erros javax.naming.NameNotFoundException no log conforme o seguinte:

   javax.naming.NameNotFoundException: Name 'jboss-seam-booking' not found in context ''

   Caso você não deseje modificar as pesquisas JNDI através do código, você pode modificar o arquivo components.xml do aplicativo, conforme abaixo:

   1. Substituição do elemento core-init existente

      Primeiro, você pode substituir o elemento core-init existente, conforme abaixo:

      <!-- <core:init jndi-pattern="jboss-seam-booking/#{ejbName}/local" debug="true" distributable="false"/>   -->
      <core:init debug="true" distributable="false"/>
      
      

   2. Encontre as mensagens INFO JNDI binding INFO no log do servidor

      A seguir, encontre as mensagens INFO binding JNDI que são emitidas no log do servidor quando o aplicativo é implantado. As mensages binding JNIDI devem parecer-se com o seguinte:

      INFO org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor (MSC service thread 1-1) JNDI bindings for session bean
      named AuthenticatorAction in deployment unit subdeployment "jboss-seam-booking.jar" of deployment "jboss-seam-booking.ear" are as follows:
          java:global/jboss-seam-booking/jboss-seam-booking.jar/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator
          java:app/jboss-seam-booking.jar/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator
          java:module/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator
          java:global/jboss-seam-booking/jboss-seam-booking.jar/AuthenticatorAction
          java:app/jboss-seam-booking.jar/AuthenticatorAction
          java:module/AuthenticatorAction
      

   3. Adição dos elementos do componente

      Para cada mensagem INFO binding JNIDI, adicione um elemento component correspondente ao arquivo components.xml:

      <component class="org.jboss.seam.example.booking.AuthenticatorAction" jndi-name="java:app/jboss-seam-booking.jar/AuthenticatorAction" />
      

   Para maiores informações de como depurar e resolver os problemas de migração, consulte a Seção 4.2.1, “Depuração e Solução dos Problemas de Migração”.
   Para uma lista de problemas de migração conhecidos com os arquivos, consulte a Seção 3.2.13.2, “Problemas de Migração do Seam 2.2 Archive”.